A green status code can conceal a broken route. A useful health check describes what the client actually needs, then verifies each boundary without turning the check itself into another system.
Start outside the service
The first check should come from the same kind of network as the user. Confirm name resolution, the address reached, the certificate presented, and the response returned. Internal checks remain useful, but they answer a different question.
- Resolve the public name and record the returned addresses.
- Establish TLS and verify the expected certificate name.
- Request a small, uncached document through the public route.
- Confirm the response body, not only the status code.
Keep transport and application facts separate
A reachable port does not prove that the application behind it can complete a request. Conversely, an application log may look quiet because a connection failed before it reached the service. Record transport, TLS, routing, and application evidence as separate facts.
Design the check for recovery
The best check also helps during restoration. It should be quick to run from a clean machine, depend on ordinary tools, and state the expected result. When the system is under pressure, clarity has more value than coverage.