If you have a Custom Maintenance Page then you will see your maintenance page instead of This application crashed.
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 occurance, see Endpoint Logs.
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.
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 allocationin 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 exitedin your logs. Your logs may also have additional information that can help you determine why your container unexpectedly exited.
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 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.
Updated 12 months ago