Health checks

A process can be running before it is ready to serve traffic. A health check helps Openstead distinguish a started container from an application that can accept requests during deployment, scaling, and ongoing operation.

Understand service statusCopy Anchor Link

Your service's current status is separate from the outcome of a previous deployment. Deploy succeeded records that a release completed successfully. Live requires the active release to have a recent successful readiness observation.

The console refreshes service state across open views. A network failure displays unknown status instead of continuing to claim the service is live. Deletion continues in the background and retries incomplete cleanup; a service disappearing from the normal list is not, by itself, confirmation that removal has finished.

Configure an HTTP checkCopy Anchor Link

Add an application route such as /health. For a web service, set Health check path to that path in the service settings. For a private service, set configuration.healthCheckPath through Update service. Deploy to apply the new release configuration.

Example Express route:

app.get("/health", (_request, response) => {
  response.status(200).json({ status: "ok" });
});

The path must begin with /. The current readiness probe issues a GET to the application's configured port and accepts HTTP 200 through 399. Aim for a direct 200 response rather than a redirect. The probe does not follow redirects and uses a short connection/read timeout.

Keep the route independent of a browserCopy Anchor Link

The endpoint must work without authentication, cookies, a CSRF token, or a custom browser header. The readiness probe reaches the instance directly rather than through its custom domain, so hostname-dependent middleware can reject it even when the public homepage works.

For frameworks with allowed-host enforcement, explicitly handle the readiness path safely. Do not disable host validation for the entire application just to make a health probe pass. Keep the health response minimal and avoid exposing configuration or database details.

Check meaningful readinessCopy Anchor Link

A basic route proves that the application server can respond. If the app cannot serve useful requests until a critical dependency is available, add a fast, bounded readiness check for that dependency and return 503 when it is unavailable.

Avoid expensive queries, schema migrations, payment-provider calls, and other side effects in the health endpoint. A fragile optional third-party API should not make every application instance fail readiness.

Without a pathCopy Anchor Link

When no HTTP path is configured, Openstead checks whether the configured application port accepts a TCP connection. This is useful for initial bring-up, but it cannot confirm that the application returns useful HTTP responses.

Workers do not expose an HTTP service for this check. Verify queue connectivity and job completion using their logs and application monitoring.

Diagnose a failed readiness checkCopy Anchor Link

1. Confirm the application listens on 0.0.0.0 and the service's configured PORT.
2. Inspect runtime logs for startup exceptions or missing variables.
3. Confirm that the health path exists and does not require login.
4. Check allowed-host, forced-HTTPS, and other middleware behavior for direct instance requests.
5. Check memory usage and initialization time if the application restarts during startup.

A public URL returning an error does not always mean the health route failed, and a passing health route does not validate every user flow. Test the application after deployment as well.