A false negative in monitoring happens when something is broken but the monitor reports success. The outage goes undetected until a customer complains.
Why it matters
False negatives are more dangerous than false positives because the failure is silent. Usually the check is too shallow. It confirms that a server answers but not that the application works. A homepage served from a CDN cache can return HTTP 200 while the login, database or checkout behind it is broken.
Example
A shop's monitor requests / and gets 200 from a cached copy. Meanwhile the checkout API returns errors for every order. Adding a keyword check and an API check closes the gap:
check 1: GET / expect status 200, body contains "Add to cart"
check 2: GET /api/health expect status 200, body contains "db":"ok"
check 3: POST /api/cart expect status 201
Common mistakes
- Relying on status code alone. Some failures return 200 with an error page.
- Monitoring only the front page and not critical journeys.
- Checking from one region, so regional failures are missed.
- Long check intervals that skip short outages.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.