The blind spot in uptime monitoring: why a 200 OK is not operational health

Uptime monitoring is the first thing most teams set up and, for years, the last thing they revisit. It is cheap, it is simple, and it answers a genuinely useful question: is this endpoint responding. The problem is not that the answer is wrong. The problem is how much it leaves out.

What a 200 OK does not tell you

A successful response code confirms that a request reached a server and the server replied. It says nothing about whether the reply was correct, fast, complete, or useful to the customer who triggered it.

• A checkout that returns 200 but rejects every payment downstream
• A page that loads in 200 OK but takes nine seconds to do it
• An API that succeeds on retry, hiding a failure rate that is quietly climbing
• A region that is failing while the global average stays comfortably green

Health is a spectrum, not a switch

The mental model behind uptime monitoring is binary: a service is up or it is down. Real systems do not behave that way. They degrade. Latency creeps. Error rates climb a percentage point at a time. A dependency starts retrying. By the time any of this trips a binary check, the degradation has usually been affecting customers for a while.

Most incidents do not begin with a service going down. They begin with a service getting worse.

The wider question

Operational health is not "is my endpoint up". It is "is everything my product depends on behaving normally, and if not, what changed and where". That question pulls in provider incidents, domain and certificate state, API latency trends, and the journeys your customers actually complete. Uptime is one input to that picture. Treating it as the whole picture is the blind spot.

Keep the uptime check. It is still the cheapest way to catch a hard failure. Just stop mistaking a green light for an operational all-clear.