A running container is not always a working app. A health check asks the app on a schedule, and shows the answer on the app's status.
There are two kinds:
| Kind | What it asks | Who asks it |
|---|---|---|
| HTTP | A path on the app, over the server's own network | Deplo, through the agent |
| Command | A shell line inside the container, read as an exit code | Docker, as a Compose healthcheck: |
The HTTP check works on any image. It is asked from outside the container, so nothing needs to be installed inside. A status under 400 is healthy.
An HTTP check never changes routing. The app keeps serving while it is unhealthy, so you can see the problem instead of losing the app.
Turn one on
Open the app's Advanced settings
Open the app, then Settings -> Advanced, and find Health check.
Pick the kind
HTTP request asks for a path. Command runs a shell line inside the
container and reads its exit code: pg_isready -U app, test -f /tmp/ready,
anything that exits 0 when things are fine.
Fill it in
For an HTTP check: the Path (/healthz, or /), and a Port if the
check is answered on a port different from the one its domains route to.
Set the timings
All optional:
| Field | What it means | Default |
|---|---|---|
| Interval | How often the app is asked | 30s |
| Timeout | How long one answer may take. Must be shorter than the interval | 5s |
| Retries | Failures in a row before the app counts as unhealthy | 3 |
| Start period | Time after the container starts where a failure reads as starting | 10s |
A command check applies on the next deploy. An HTTP check applies immediately.
Reading the result
The result shows in two places: the app's status badge, and the container breakdown on Monitoring.
- Healthy - the last answer was good, or the failures so far are still under Retries.
- Unhealthy - Retries failures in a row. The app is running but not working.
- Starting - inside the start period, so a failure means the app is still booting.
One good answer resets the failure count.
Error is not unhealthy. Error means the last deploy failed. An app can be Error and healthy at the same time, because the previous version is still serving.
Good to know
- Results are kept in memory, like the monitoring history. Restarting Deplo clears them and the next check starts again.
- A stopped app has no result. There is nothing to ask.
app_crash_loopis a different alert. It fires when a container restarts over and over, not on a failed check. See Notifications and alerts.- A database's health check is the engine's own, written by Deplo when it creates the database. It is not editable here.
Next steps
Did this page help you?