Add Django health checks

Health checks are HTTP requests that Sevalla sends to each instance of the web process. The readiness probe decides when an instance gets traffic: during a deployment, new instances receive requests only once it passes. The liveness probe restarts an instance that stops responding. A Django project needs two endpoints for them, one that checks the database and one that only checks that Django answers.

At a glance

This guide adds to the application from Deploy a Django application:


Health check	Readiness probe: `GET /healthz` returns `200` when the database accepts a connection, `503` when it doesn’t. Liveness probe: `GET /livez` returns `200`, after an initial delay of 10 seconds

Environment variables

This guide adds no environment variables. The deploy guide lists the variables the project needs.

Before you begin

A Django project deployed on Sevalla, as in Deploy Django.

Add the endpoints

The probes call the instance directly, without your domain in the Host header, so a normal view would fail Django’s ALLOWED_HOSTS check with 400 Bad Request. Answer the probes in a middleware that runs before anything reads the host:

storefront/health.py

from django.db import connection
from django.http import HttpResponse


class HealthCheckMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        if request.path == "/livez":
            return HttpResponse("OK")
        if request.path == "/healthz":
            try:
                connection.ensure_connection()
            except Exception:
                return HttpResponse("Database unavailable", status=503)
            return HttpResponse("OK")
        return self.get_response(request)

Put it first in MIDDLEWARE in storefront/settings.py:

storefront/settings.py

MIDDLEWARE = [
    "storefront.health.HealthCheckMiddleware",
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",
    # ...the rest of the middleware...
]

/healthz returns 200 when the database accepts a connection and 503 when it doesn’t. Use it for readiness: an instance that can’t reach the database gets no traffic.
/livez returns 200 whenever Django runs. Use it for liveness, so that a database outage doesn’t restart every instance.

Add more checks to /healthz for each service the application can’t work without, such as cache.get("health") for a Redis cache. Commit and push the changes, and wait for the deployment to finish before you turn on the probes.

Turn on the health checks

Open the web process

On the application’s Processes tab, click ⋯ on the Web process, then click Update process.

Turn on the readiness probe

Under Health checks, turn on Readiness probe and set the Path to /healthz. Keep the Port at the web process’s port, 8080 unless you changed it.

Turn on the liveness probe

Turn on Liveness probe, set the Path to /livez, and set the Initial delay to 10 seconds, so a slow start doesn’t count as a failure.

Save and deploy

Click Update process, then click Deploy in the undeployed changes bar at the bottom of the page.

The sheet for updating the web process, with its start command, resource, scaling and the Health checks section with the readiness probe on

A probe passes when the path answers with a status from 200 to 399 within the timeout (1 second by default). Ingot’s Gunicorn settings give each worker process 4 threads, so a slow page doesn’t hold up the probes. Only the web process has health checks. See Health checks for every probe setting and its default.

Verify

Request the endpoints through your domain: curl -i https://storefront-x7k2m.sevalla.app/healthz returns status 200 with the body OK, and so does /livez. The middleware answers before the host check, so the probes get the same answer when they call the instance by its IP address.
On the Deployments tab, the deployment that turned on the probes reaches Deployed.

From a shell, with your application’s domain, and with APP_ID and WEB_ID from Deploy with the API for Get process (getProcessV3):

curl -s -w ' %{http_code}\n' https://storefront-x7k2m.sevalla.app/healthz
curl -s -w ' %{http_code}\n' https://storefront-x7k2m.sevalla.app/livez
curl -s "$API/applications/$APP_ID/processes/$WEB_ID" -H "Authorization: Bearer $SEVALLA_API_KEY" \
  | jq -c '{readiness: .readiness_probe.httpGet.path, liveness: .liveness_probe.httpGet.path}'

OK 200
OK 200
{"readiness":"/healthz","liveness":"/livez"}

If the deployment doesn’t finish, click App health on the Overview tab to see each instance’s status. An instance that fails the readiness probe shows Unready: request the path yourself and check that it returns 200, and that the Port matches the port Gunicorn listens on.

Deploy with the API

This sequence turns on the probes of the application from Deploy with the API and continues in its shell, with API, APP_ID and WEB_ID set. Push the code changes from Add the endpoints first, and let that deployment finish. Each step names the CLI command and the Sevalla MCP server tool that do the same.

Turn on the probes

Update process (updateProcessV3) sets both probes with the dashboard’s defaults. Send timeoutSeconds: a probe set through the API without it gets 120 seconds, not the dashboard’s 1:

curl -s -X PATCH "$API/applications/$APP_ID/processes/$WEB_ID" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "readiness_probe": {"httpGet": {"path": "/healthz", "port": 8080}, "initialDelaySeconds": 0, "periodSeconds": 10,
      "timeoutSeconds": 1, "successThreshold": 1, "failureThreshold": 3},
    "liveness_probe": {"httpGet": {"path": "/livez", "port": 8080}, "initialDelaySeconds": 10, "periodSeconds": 10,
      "timeoutSeconds": 1, "successThreshold": 1, "failureThreshold": 3}
  }' | jq -c '{readiness: .readiness_probe.timeoutSeconds, liveness: .liveness_probe.timeoutSeconds}'

It prints {"readiness":1,"liveness":1}. Use the web process’s port if you changed it from 8080. CLI: not available, sevalla apps processes update has no probe options. MCP: sevalla_api_update with updateProcessV3 and the same body.

Deploy

Trigger deployment (triggerDeploymentV3). The probes apply from this deployment:

DEPLOYMENT_ID=$(curl -s -X POST "$API/applications/$APP_ID/deployments" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" -H "Content-Type: application/json" -d '{}' | jq -r .id)

CLI: sevalla apps deployments trigger "$APP_ID". MCP: trigger_deployment.

Wait for the deployment

Get deployment (getDeploymentV3) reports the status, which ends as success, failed, cancelled or skipped. The loop keeps polling through a failed request, for up to 30 minutes:

for i in $(seq 1 120); do
  STATUS=$(curl -s "$API/applications/$APP_ID/deployments/$DEPLOYMENT_ID" \
    -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.status // empty')
  case $STATUS in success|failed|cancelled|skipped) break ;; esac
  sleep 15
done
echo "$STATUS"

CLI: sevalla apps deployments get "$DEPLOYMENT_ID" --app-id "$APP_ID". MCP: get_deployment.

Then run the checks in Verify.

Get started

Migrate

AI

JavaScript

Python

PHP

Ruby

Go

Rust

Java, Kotlin and Scala

.NET

Elixir

Gleam

Swift

Dart

Static site generators

Add Django health checks

At a glance

Environment variables

Before you begin

Add the endpoints

Turn on the health checks

Verify

Deploy with the API

​At a glance

​Environment variables

​Before you begin

​Add the endpoints

​Turn on the health checks

​Verify

​Deploy with the API

At a glance

Environment variables

Before you begin

Add the endpoints

Turn on the health checks

Verify

Deploy with the API