📘 If you have a Custom Maintenance Page then you will see your maintenance page instead of Application is currently unavailable.

​
Cause and Resolution

This page will be served by Aptible if your App fails to respond to a web request. There are several reasons why this might happen, each with different steps for resolution: For further details about each specific occurrence, see Endpoint Logs.

​
The Service for your HTTP(S) Endpoint is scaled to zero

If there are no Containers running for the Service associated with your HTTP(S) Endpoint, this error page will be served. You will need to add at least one Container to your Service in order to serve requests.

​
Your Containers are closing the connection without responding

Containers that have unexpectedly restarted will drop all requests that were running and will not respond to new requests until they have recovered. There are two reasons a Container would restart unexpectedly:
  • Your Container exceeded the Memory Limit for your Service. You can tell if your Container has been restarted after exceeding its Memory Limit by looking for the message container exceeded its memory allocation in your Logs. If your Container exceeded its Memory Limit, consider Scaling your Service.
  • Your Container exited unexpectedly for some reason other than a deploy, restart, or exceeding its Memory Limit. This is typically caused by a bug in your App or one of its dependencies. If your Container unexpectedly exits, you will see container has exited in your logs. Your logs may also have additional information that can help you determine why your container unexpectedly exited.

​
Your App is taking longer than the Endpoint Timeout to serve requests

Clients will be served this error page if your App takes longer than the Endpoint Timeout to respond to their request. Your Logs may contain request logs that can help you identify specific requests that are exceeding the Endpoint Timeout. If it’s acceptable for some of your requests take longer than your current Endpoint Timeout to process, you can increase the Endpoint Timeout by setting the IDLE_TIMEOUT Configuration variable. Hitting or exceeding resource limits may cause your App to respond to requests more slowly. Reviewing metrics from your Apps, either on the Aptible dashboard or from your Metric Drains, can help you identify if you are hitting any resource bottlenecks. If you find that you are hitting or exceeding any resource limits, consider Scaling your App. You should also consider deploying Application Performance Monitoring for additional insight into why your application is responding slowly. If you see the Aptible error page that says “This application crashed” consistently every time you release your App (via Git push, aptible deploy, aptible restart, etc.), it’s possible your App is responding to Aptible’s Release Health Checks, made via GET /, before the App is ready to serve other requests. Aptible’s zero-downtime deployment process assumes that if your App responds to GET /, it is ready to respond successfully to other requests. If that assumption is not true, then your App cannot benefit from our zero-downtime approach, and you will see downtime accompanied by the Aptible error page after each release. This situation can happen, for example, if your App runs a background process on startup, like precompiling static assets or loading a large data set, and blocks any requests (other than GET /) until this process is complete. The best solution to this problem is to identify whatever background process is blocking requests and reconfigure your App to ensure this happens either (a) in your Dockerfile build or (b) in a startup script before your web server starts. Alternatively, you may consider enabling Strict Health Checks] for your App, using a custom healthcheck request endpoint that only returns 200 when your App is actually ready to serve requests.
📘 Your Endpoint Logs will contain a specific error message for each of the above problems. You can identify the cause of each by referencing Endpoint Common Errors.