Health Checks

Configuring the Probe Path

In your service's Settings → Health Check tab, set:

• Health check path — no default. If you leave it blank, HostStack probes the container root (/) during the deploy readiness gate and just confirms the server is accepting connections (any response below 500 counts). Set an explicit path that returns 2xx to also enable ongoing health monitoring after the deploy — without a path, there is no continuous probe.
• Checks always run over plain HTTP against your service's configured port (default 3000), even when the public domain is HTTPS. There is no protocol or port field to set.

Interval, Timeout & Grace Period

interval:     30s   (5–300s)    how often the ongoing probe runs
timeout:       5s   (1–30s)     per-probe request timeout
grace period: 120s  (1–1800s)   how long a new replica has to go healthy
                                 before the deploy is rolled back

When a path is configured, the ongoing probe runs on its interval whether or not real traffic is reaching the replica, so a flat-lined dependency surfaces quickly even on idle services. The grace period governs the zero-downtime cutover: a freshly-started replica must answer the probe within it, or the new container is discarded and the old one keeps serving.

Container HEALTHCHECK

Define a HEALTHCHECK in your Dockerfile to control readiness — when HostStack adds a freshly-started replica to the Traefik pool. Zero-downtime deploys rely on the container reporting healthy before the old replica is drained.

HEALTHCHECK --interval=10s --timeout=3s --start-period=30s --retries=3 \
  CMD curl -fsS http://localhost:3000/health || exit 1

Liveness vs Readiness

Most apps don't need separate liveness and readiness endpoints — one path that returns 200 once the app is ready to take requests is enough. If you want a deeper readiness probe (e.g. "DB pool is up"), point HostStack at that path and keep /health as a shallow liveness probe in your Dockerfile.