![Server monitoring response validation showing endpoint returning 200 OK with degraded status content triggering correct alert in Netglare monitoring dashboard](/sites/default/files/styles/large_1600x900/public/2026-09/Telephone-I%27m-fine.webp?itok=ZwPTEuVJ) - [09 September 2026](#) - [ 5 min read ](#) ### Your Server Said It Was Fine. It Wasn't. Server monitoring response validation is the kind of feature that sounds obvious once you understand why it's necessary and makes you slightly uncomfortable when you realize how long monitoring worked without it. Most monitoring tools, including most of the well-known ones, check whether your endpoints respond. They send a request, receive a 200 OK status code, mark the endpoint as healthy and move on. That's the baseline and for a long time it was sufficient because a server that responds is usually a server that's working. Modern infrastructure broke that assumption quietly and completely. ## **The 200 OK Lie** Here's how the lie works. Your application has a health check endpoint, a URL that exists specifically to tell monitoring systems whether the application is healthy. When everything is working, it returns something like {"status":"ok"} with a 200 status code. When something is wrong, it returns {"status":"degraded"} or {"status":"error"} with, in many cases, a 200 status code. Because the endpoint itself is working fine. It's just reporting that the application behind it isn't. A monitoring tool that checks for the 200 sees a healthy response. Your users see a broken application. The monitoring tool continues reporting that everything is fine while your support inbox fills up with complaints about the thing that isn't fine. The server answered the phone, said everything was terrible, and the monitoring tool hung up satisfied because the phone was answered. This isn't a hypothetical. It's a failure pattern that happens regularly in production environments and it's the kind of failure that's particularly insidious because your monitoring tells you there's no problem while your users tell you there very much is. ## **What Server Monitoring Response Validation Actually Does** The fix is conceptually straightforward even if the implementation requires some care. Instead of just checking whether an endpoint responds, [Netglare ](https://netglare.com)now checks what the endpoint responds with. You configure what a healthy response looks like for each endpoint you're monitoring: a JSON path that points to the field you want to check, an operator that defines what check to run, and an expected value that defines what healthy looks like. A health check endpoint that should return {"status":"ok"} can now be configured to alert if the status field contains anything other than "ok." An API endpoint that should always return a non-empty results array can be configured to alert if results doesn't exist or is empty. A payment processing endpoint that should never return {"errors":true} can be configured to alert the moment that field appears in a response regardless of what the HTTP status code says. When a response doesn't match the configured expectation, Netglare treats it with the same urgency as a complete outage because from the user's perspective the experience is often identical. A server confidently returning the wrong answer is a failure regardless of the politeness of its HTTP response code. ## **The Feature That Was Invisible** The second thing we shipped today is one of those discoveries that's slightly embarrassing to admit and important to talk about anyway. Netglare can now tell you exactly why an endpoint failed in your alert notifications. That sounds like something it should always have been able to do and until today it couldn't, not in the places that matter. The failure reason logic was fully built on the backend. Every time an endpoint failed, Netglare correctly identified and stored whether it was a content check failure, an error message, an unexpected HTTP status code, or an unreachable endpoint. That information existed, was correctly prioritized, and was completely absent from the actual alert notifications that users received. You'd get a notification telling you something was wrong with no explanation of what triggered it. We caught this mid-build during testing rather than after launch, which is the correct time to catch it and also not as early as we'd have liked. The failure reason now appears in every notification channel, email, Slack and Telegram, in a consistent priority order: content check failure with the specific detail first, then error message, then HTTP status code, then unreachable. The alert now tells you what happened so you can start investigating the right thing immediately instead of opening dashboards to find out what the notification should have told you. ## **The Two Bugs We Found And Fixed In Production** The third thing that shipped today is less philosophically interesting and more practically important: two production bugs that we found, broke further in the process of fixing, and eventually resolved correctly. The first was incident notification spam. Netglare was sending alert notifications every five minutes for ongoing incidents instead of once when the incident started and once when it resolved. The result was that a two hour outage would generate twenty four notifications rather than two, which is the monitoring equivalent of a smoke alarm that keeps going off after you've already called the fire brigade and are standing in the garden watching it burn. Finding bugs in production is always less comfortable than finding them during testing, which is exactly why we ran [107 end-to-end tests before launch](/blog/107-ways-to-break-we-fixed-them-all). The fix ensures each incident generates exactly the notifications it should: one when it starts, one when it ends. The second was a UI bug in the endpoint management interface that took several rounds to diagnose properly because the symptoms appeared in one place and the root cause lived somewhere else entirely. The visible problem was a modal that wasn't updating correctly after certain interactions. The actual cause was a reactivity conflict between two of the frontend libraries we use, where one library's system for updating the interface was getting out of sync with the other's after a specific sequence of DOM changes. Fixing the visible symptom without finding the actual cause produced a different version of the same problem. Finding the actual cause required working backwards through several layers of abstraction until we reached the specific interaction that was breaking the expected behavior. Fixed by changing the approach to how the interface updates rather than patching the symptom. ## **What Today's Release Means** Server monitoring response validation closes a gap that's been present in uptime monitoring since uptime monitoring existed. Failure reason propagation closes a gap we created ourselves and caught before it reached production users. The production bug fixes close gaps that real usage found before real users did. Response validation is also the kind of accumulated intelligence that compounds over time, feeding into the same [data layer that makes Netglare's monitoring smarter](/blog/saas-competitive-moat-moat-or-mort) the longer you use it. That's what a shipping day actually looks like. Some of it is philosophical progress in how monitoring should work. Some of it is honest correction of things that should have been right the first time. All of it makes the product more useful to the people using it. Head to netglare.com to see what your monitoring could look like with response validation enabled. Or reach out at to talk through your specific monitoring setup. Share: - [ ](https://www.facebook.com/sharer/sharer.php?u=https://gatoblan.co/markdownify/node/59&title=Your%20Server%20Said%20It%20Was%20Fine.%20It%20Wasn%27t. "Share to Facebook") - [ ](https://twitter.com/intent/tweet?text=Your%20Server%20Said%20It%20Was%20Fine.%20It%20Wasn%27t.+https://gatoblan.co/markdownify/node/59 "Share to X") - [ ](https://www.linkedin.com/sharing/share-offsite/?url=https://gatoblan.co/markdownify/node/59 "Share to Linkedin") - [ ](mailto:?subject=Your%20Server%20Said%20It%20Was%20Fine.%20It%20Wasn%27t.&body=https://gatoblan.co/markdownify/node/59 "Share to Email")