“Healthy” is meaningful only when you know what was tested. A running process, a server ready to accept traffic, and a working public URL are related—but different—facts.
Liveness: should this process be restarted?
Liveness checks are about whether an application is stuck in a condition that restarting can address. They should not casually turn a shared dependency outage into a restart storm.
If every instance restarts because the same database is unavailable, the restart may add load without repairing the database.
Readiness: should this instance receive traffic?
Readiness concerns whether an instance can serve requests now. An instance can be alive while still initializing, loading configuration, or waiting for a required dependency.
Kubernetes separates liveness, readiness, and startup probes: readiness affects traffic eligibility, while repeated liveness failures can trigger a restart; startup probes allow initialization to finish before the other probes take over. Its probe documentation explains the behavior and configuration.
Those terms are useful outside Kubernetes too, but check how your own deployment platform implements them rather than assuming identical semantics.
External monitoring: can the public path be reached?
A local check can pass while DNS, routing, a reverse proxy, or certificate configuration prevents customers from reaching the service. A public-URL check exercises another portion of the path.
The reverse can also happen: a cached homepage remains available while a critical backend is broken. Use a representative application endpoint as well as the public entry point.
Write the contract before the endpoint
For each health endpoint, document:
- What a successful response establishes.
- Which dependency failures make it fail.
- What the caller does after failure.
- How much work each request performs.
That third question matters most. A check that pages someone can tolerate different behavior from one that restarts every application instance.
Do not expose detailed diagnostics just because the endpoint is called “health.” Return the minimum useful signal and keep sensitive investigation data behind appropriate access controls.
Use deployment health checks to manage instances and external monitoring to observe reachability. Neither is a substitute for testing the customer workflow after a release.