Coolify Health Checks: Define Readiness Around a Real Request

A useful Coolify health check answers whether the new application instance can receive the requests you intend to route to it. It should be cheap, predictable and connected to application readiness. It should not pretend to certify every feature or hide a failure behind an unconditional success response.

Coolify's health-check documentation describes container readiness and the effect of health state on supported proxy routing. Verify the behavior for your actual proxy configuration rather than assuming every deployment uses the same routing path.

Define what must be ready

List the minimum conditions required to serve the application. The process listening on a port may be necessary without being sufficient. Configuration loading or an essential dependency may still be unavailable.

Choose checks that represent those conditions without causing expensive work on every probe. Avoid a health request that sends messages, creates records or performs a full content crawl.

Keep optional dependencies separate. An unavailable analytics destination should not automatically mean that a product catalogue cannot serve readers.

Match the probe to the running instance

Confirm the scheme, port and path from inside the container's relevant network context. A path that works through a public hostname may depend on routing or authentication unavailable to the container probe.

Use a minimal response with no secrets. Give operators enough information to identify the failing condition without exposing connection strings or private application data.

Set timing based on observed startup behavior and the product's tolerance, then test it. An overly aggressive check can reject a healthy instance before it finishes necessary initialization.

Keep readiness distinct from product correctness

pinit.lol describes a product-discovery map and has a declared association in the Coolify catalogue. That association does not show how its health checks are configured.

For a similar directory workflow, a ready process should still be followed by a public-page smoke test: open a listing, follow its canonical link and confirm a representative data-backed view. Those checks answer questions a lightweight health endpoint cannot.

The deployment record should state which evidence came from the probe and which came from the real route.

Test the unhealthy path deliberately

In an isolated environment, make the readiness condition fail and observe routing. Confirm that the result matches the documented proxy behavior and that the operator can identify the unhealthy instance.

Then restore the condition and verify recovery. A health system that can detect failure but leaves traffic permanently stranded is incomplete.

Do not use production traffic as the first rehearsal for this behavior. A representative staging setup can reveal configuration mistakes without turning a probe experiment into an outage.

Make the release decision reviewable

Record the application artifact, readiness result, public route checks and rollback reference. A successful image build or upload is an intermediate event, not the evidence that users can reach the new version.

Keep database compatibility in the release decision. A previous application image may no longer be a valid rollback target after a data change, even if its health endpoint returns success.

The companion Coolify backup verification guide covers the data recovery side. Together, these checks provide a clearer release boundary than a single green container status.