Skip to main content
A health check tells us how to tell whether your is ready and still working. We send an HTTP request to each instance on a schedule. It’s optional, and you set it per .

​
What the health check does

  • An instance gets no traffic until it passes. So a deployment can wait for your app to finish starting before the first request arrives.
  • An instance that fails failureThreshold checks in a row is restarted.
A GET check passes on any status from 200 to 399. Anything else, including a timeout, is a failure. Without a health check, an instance is ready as soon as its container is running, and it’s only restarted if the process exits. That’s fine for apps that are ready as soon as they open the port. Add a check if startup takes a while, or if your process can be running but unable to serve.

​
Choose what to check

Check the process, not its dependencies. A failing check restarts the container, so a check that queries your database takes every instance down when the database has a bad minute. GET /healthz returning 200 is enough.

​
Add a health check

App Settings runtime section showing instances, max CPU, memory, storage, healthcheck, port, and command for production and preview
In the dashboard, open the app’s settings and use the Health check card. In the API, set healthcheck in runtime settings with environments.updateSettings:
Add a check with a shorter timeout
Like every runtime setting, it applies from the next deployment. To remove the check, use the remove action on the card, or send "healthcheck": null.

​
Fields

Only method and path are required. The others use the defaults below.
​
GET | POST
required
The HTTP method. POST sends an empty body using wget inside your container, so your image must include wget.
​
string
required
The path to request on your app’s port, 1 to 512 characters, starting with / and matching ^(/[\w\-]+)+(\.[\w]+)?$, for example /healthz.
​
integer
default:"10"
Seconds between checks, 1 to 3600. The dashboard defaults to 30s and accepts values like 15s, 2m, or 1h.
​
integer
default:"5"
Seconds to wait for a response before the check fails, 1 to 3600. Only settable in the API. Saving from the dashboard sets 5.
​
integer
default:"3"
Failures in a row before the instance is restarted, 1 to 100. Only settable in the API. Saving from the dashboard sets 3.
​
integer
default:"0"
Seconds after the container starts before the first check, 0 to 3600. Only settable in the API. Saving from the dashboard sets 0.

​
Next steps

Instances and autoscaling

How readiness, restarts, and traffic distribution fit together.

Deployments

How a deployment waits for healthy instances across regions.
Last modified on September 29, 2026