Debugging
There are several potential issues you can encounter while containerising your web application. This list provides you with helpful pointers on how to debug Divio Cloud deployment problems:
Deployment shows "Last deployment failed"
Open the link stating "Last deployment failed" to see the deployment log. The relevant section will be towards the end, so work backwards from the end. Any error will be clearly stated.
The error message will give you a hint about what went wrong. You can expand this by clicking on the Logs section of the application from the left or the environment card. There, you have access to all of the logs for that application.
If there is no apparent error in the logs, you can try to deploy the application again. Sometimes, the error is transient and a re-deployment will fix it.
Deployment succeeded, but the application is not reachable
The build process succeeded without errors, creating an image and then releasing containers that passed all health checks, but all the same, the site is not working as expected. This error should not occur but can happen in specific circumstances.
To debug this further, check the application Logs for the failing environment. The logs will contain more information about the problem. If the logs don't contain a traceback revealing a programming error, the most likely issue is that the application was too slow to start up.
Application logs show "unable to connect to the application"
The logs show an error similar to the following:
Trying to connect to the application (0:00:29.486784 with 29 retries)... connection error.
Endpoint verification failed. The client application is not responding to HTTP requests.
The load balancer was unable to connect to each of the environment's newly launched containers and obtain a positive server response within the given timeout of making the connection. The environment's Logs will contain more information about the problem. If the logs don't contain a traceback revealing a programming error, the most likely issue is that the application was too slow to start up.
To test further, check if the application is working locally. If it isn't, debug locally to get the application running. This process will depend on the technologies you are using. Consult their respective documentation for more information. If it is working locally, then follow the next section.
Application works locally but not on the cloud
Please read about the sanity tests that we perform to understand the difference between the local and cloud environments.
The most common issue between those environments is that a different command is run locally through the docker-compose.yml file than in the Dockerfile. To mimic the cloud environment, remove the command line from the docker-compose.yml file.
Additional differences may be:
- Environment variables: The environment variables set in the cloud environment are different from the local environment. Check the environment variables set in the cloud environment and compare them with the local environment.
- Services: The services running in the cloud environment are different from the local environment. Check the services running in the cloud environment and compare them with the local environment.
Application shows "Application not responding" or "Gateway timeout error"
This indicates that the ingress controller couldn't connect to your application. You should see an error message in the logs, such as Endpoint verification failed. The client application is not responding to HTTP requests..
Look at the sanity tests that we perform to ensure a connection to your application can be established.
Deployment shows "Server is offline" or "No application found"
This error indicates that the container is not running. This issue can happen to test environments that have not been used for a long time. Deploying the application again will restore its latest state.
Deployment shows "No matching distribution found"
This error occurs when the package you are trying to install is unavailable. The package may have been removed or renamed. Depending on your region, it may also be an issue with the package manager's CDN. Check if the application is building locally for you. To debug the problem further, look at how to manage your dependencies.
This is also a common issue when using the Wheels Proxy. Try re-deploying your application after a few minutes, as the wheels proxy might need some time to build the package. It can take longer for complex packages such as numpy. This applies to applications created with our "Aldryn" templates that have the wheelsproxy setup as pip index.
Deployment stuck at "Waiting for a free worker"
The Divio Cloud Platform uses Divio Workers to build and deploy your applications. Typically, this message only appears for a few seconds. Even if there's a surge in deployments, rest assured that a worker will become available eventually. You just need to wait for your turn in the queue.
Further debugging
- Consult the documentation for your technology stack.
- Check status.divio.com for any service disruptions.
- If you are still unable to resolve the issue, contact support.