Imagine a deployment that serves the application shell correctly but breaks the API behind it. A request to the homepage gets a successful response. A customer sees a loading spinner forever.
The monitor is not necessarily malfunctioning. It is answering a narrower question than you intended to ask.
Make the assertion match the question
“Does this URL answer?” is useful. “Can a customer retrieve their dashboard?” is different. Write down what a monitor proves before choosing its endpoint.
An HTTP check can establish reachability and inspect a response. It does not automatically execute browser JavaScript, complete authentication, or verify a multi-step purchase. Those require additional tests and suitable tooling.
Google's SRE guidance distinguishes externally visible symptoms from internal diagnostic signals. Both matter; neither replaces the other. See Monitoring Distributed Systems.
Check content, but choose it carefully
A stable response marker can distinguish your application from a generic maintenance page. Avoid matching a timestamp, a translated heading, or promotional copy that changes every week.
For an API, a dedicated bounded health response is often easier to maintain than a full customer response. Keep it free of personal data and secrets. If you match a marker, make sure it cannot also appear in your error template.
Do not turn health checks into production traffic generators
A health request should not create an order, enqueue an email, or modify a user record. Repeated checks can make a seemingly harmless side effect expensive.
Also avoid a readiness endpoint that performs a huge query on every request. The test should provide useful evidence without becoming a source of load itself.
Return a failure honestly
If a service is temporarily unable to handle requests, HTTP 503 communicates that condition. A Retry-After header can indicate when a client should try again, when you have a useful estimate. See the MDN 503 reference.
That does not mean changing every optional dependency failure into a total outage. Define which capabilities are essential, then report partial failures separately.
Review your first monitor today: what could break while it stayed green? That answer is usually your next check. The first-five-monitors guide gives you a practical starting set.