A health check that returns 200 while everything else fails
The liveness probe answered fine for an hour while every real endpoint returned 503. That is worse than having no probe.
5 Sept 2026
Building this index we ran a crawl at six concurrent requests against a Telegram gateway. It took the service down in about six minutes — every real endpoint returning 503 for the next hour.
Throughout, /health returned 200 {"status":"ok"}.
Why that is worse than nothing
A probe that does not touch the thing the service exists for is not a weaker signal. It is a false one. Teams point monitoring at it, the dashboard stays green, and the outage is discovered by a customer instead.
Had there been no /health at all, the monitoring would have been built against a real endpoint and would have fired.
What a useful probe looks like
It exercises the dependency that actually fails. For a service wrapping a stateful protocol, that means touching the session — a cheap fixed lookup with a short cache is enough. It costs one upstream call a minute and tells you the truth.
The tell is in the failure message. Ours suggested calling a specific endpoint "first", which means the service has warm-up state. Any probe that does not exercise that state is measuring the HTTP server, not the product.
The general rule
Ask what your health check would have caught in your last outage. If the answer is nothing, it is decoration.
The same reasoning shapes this site: the build refuses to publish if the measurement is stale or the aggregate moves implausibly, because a pipeline that fails quietly and keeps publishing is the same failure in a different costume.
Run the same measurements yourself
Free tier, no card. Every figure above came from one endpoint on a weekly schedule.