The /healthz endpoint exposes the health of the nSelf backend to nginx upstream probes, load balancers, and monitoring systems.

Returning 200 on degraded prevents nginx from marking the upstream as failed during transient Hasura slowness (e.g. a GC pause or query spike). Only a hard 503 signals to nginx that the upstream should be bypassed.

Set in .env (or deployment secrets) to tune the threshold:

# Lower threshold — prefer fast failover
HEALTHZ_HASURA_TIMEOUT_MS=500

# Higher threshold — tolerate slow cold-start
HEALTHZ_HASURA_TIMEOUT_MS=5000

The nginx location = /healthz block must use compatible timeouts so nginx does not cancel the request before the nSelf handler can return a 200 degraded:

location = /healthz {
    proxy_pass         http://hasura:8080/healthz;
    proxy_connect_timeout 3s;
    proxy_read_timeout    5s;
    proxy_send_timeout    3s;
}

For nginx Plus upstream health_check directives, use valid_statuses 200 503 and fail_timeout 10s so that 200 degraded does not trigger an upstream penalty:

upstream backend {
    server hasura:8080;
    health_check uri=/healthz valid_statuses=200,503 fail_timeout=10s;
}

This config is documented but not auto-generated by nself build (nginx Plus feature). For open-source nginx, the proxy_connect_timeout / proxy_read_timeout values in sites/hasura.conf are sufficient.

# Healthy — Hasura running
curl -s http://localhost:8080/healthz | jq .
# {"status":"ok","hasura":"ok"}

# Degraded — simulate with a low threshold and slow Hasura
HEALTHZ_HASURA_TIMEOUT_MS=50 curl -s http://localhost:8080/healthz | jq .
# {"status":"degraded","hasura":"slow"}

# Down — Hasura stopped
docker stop <project>_hasura
curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/healthz
# 503

• Config-Hasura — Hasura service configuration
• Config-Nginx — nginx configuration reference
• operations/self-healing — watchdog and auto-restart behaviour
• Home