Our frontend deployed clean. The build passed, the health check came back 200, the dashboard was green. And every order quietly stopped.
The deploy had shipped pointing at the wrong API address. The site loaded fine, the pages rendered, nothing threw a server error. But every call the app made under the hood was going to the wrong place, so nothing a real user tried to do actually worked. Sign in, add to cart, place an order: all of it failed silently, in the browser, where no 200 check could see it.
We didn't find out from monitoring. We found out because our anomaly detection started alarming that orders weren't coming in. By the time we traced it back and reverted, we had lost thousands of orders. The dashboard was green the entire time.
That gap, between "the server answered" and "a user got what they came for," is the most expensive blind spot in most monitoring setups. A 200 response means your server received a request and answered without crashing. It does not mean the page worked, the JavaScript loaded, the API calls reached the right place, or a single person completed a test. Your uptime monitor can stay green while every order fails.
What a 200 actually tells you
When an uptime monitor checks your site, it sends an HTTP request to a URL and waits for a response. If the response is 200, the check passes and the dashboard stays green.
A 200 means one thing: the server received the request and responded without crashing. It does not mean the page rendered in a browser, the JavaScript bundle loaded, third-party scripts initialized, the form accepted input, the API calls went where they should, the payment processed, or a confirmation appeared.
Your server can return 200 on every request for an hour while checkout is broken for every user who tries it. The monitor never knows, because the monitor never tried to check out.
The failures a ping will never catch
The wrong-API-address deploy is one flavor of this. Here are others, all of which return a clean 200 while users hit a wall.
A misconfigured deploy points the app at the wrong place. This was ours. Config drift, a bad environment variable, a stale base URL. The HTML loads, the monitor is happy, and every API call fails in the browser. Nothing reaches your server logs, because the calls never reach your server.
A stale CDN node serves HTML for a JavaScript file that no longer exists. You deploy, your edge nodes still cache the old HTML referencing main.a4f2c.js, your new build emits main.c8d13.js. Visitors get a valid HTML document and a blank page, because the script 404s. The monitor requested the HTML and got its 200.
A third-party script fails and takes the form with it. Stripe's CDN blips, or a tag manager update throws before your payment form initializes. The page renders, the button appears, the user clicks, nothing happens. The failure lives entirely in the browser, before any request leaves the page. Your monitor pinged the URL and saw 200.
A processor degrades without going down. Payment APIs have incidents that are not outages. Latency spikes, a chunk of requests time out client-side, and the processor is technically still responding. Your server is technically fine. A portion of your checkouts are silently failing, and no status check registers it.
A webhook returns 200 but never does the work. A user pays, Stripe fires payment_intent.succeeded, your handler returns 200 fast enough to satisfy the timeout, and then the database write fails silently. The order is never created. The customer paid and is waiting for a confirmation that will never come. Your endpoint is returning 200 every time.
The pattern is the same in every case. The thing being measured (did the server answer?) is not the thing you care about (did the user succeed?).
The most expensive incidents are the quiet ones
Total outages get caught fast, because everything screams at once. The incidents that bleed money are the silent ones, where the dashboard stays green and the failure only shows up in business metrics.
Sentry documented a retailer whose checkout broke for a segment of users during Black Friday because of a browser extension incompatibility. Perfect uptime the whole time. Conversion dropped, and it went undetected for weeks. In the same writeup, a payments company had every SLO green while cross-border transfers failed intermittently, visible only in tail latency.
Gremlin described a processor incident where the monitoring showed nothing unusual, just a slight traffic dip and no error spikes, while roughly $800,000 in gross revenue disappeared in an hour. $800K, no alerts.
In our case it was anomaly detection on orders that caught it, not anything in the monitoring stack. That is the tell. When the thing that saves you is "revenue looks wrong," your monitoring missed the failure entirely.
The industry is very good at the wrong question
The standard answer to all this is to add more signal: keyword checks that look for text on the page, multi-region pings, status-page aggregation. These help. A check that looks for "Add to Cart" on the page will catch more than a raw 200.
But they still don't run the test. They look at a page. They don't click the button, fill the form, enter a card number, and confirm an order was placed. There is a real difference between checking whether a checkout page exists and checking whether checkout works, and the industry has gotten very good at the first one.
As the Sentry team put it: your uptime is not your product. Users succeeding is your product.
The question worth answering
Not "did my server respond?" Not "does the checkout page exist?" Not "is uptime above 99.9%?"
Can a user go to my site, sign in, add something to the cart, enter a card, and see a confirmation, right now?
The only way to answer that is to do it. Open a real browser, walk the test, check for the confirmation. Do it after every deploy, and do it on a schedule so you catch the failures that happen with no deploy at all, like a third-party blip or a config that drifted. That is a smoke test. Not a ping, a test.
If we had been running one against checkout, we would have known about the wrong API address in minutes, from a failed test and a recording of exactly where it broke, instead of hours later from a revenue alarm. The difference between "your uptime monitor says 200 OK" and "your checkout is broken" is the difference between checking that the door exists and checking that it opens.
FAQ
Why doesn't uptime monitoring catch checkout failures?
An uptime monitor sends an HTTP request and checks whether the server responds. A 200 means the server did not crash. It says nothing about whether the page rendered, whether JavaScript loaded, whether API calls reached the right place, or whether a form submission completed. Most checkout failures happen in the browser or in downstream services, both invisible to a ping.
What is the difference between uptime monitoring and smoke testing?
Uptime monitoring checks whether a server is responding. Smoke testing checks whether a user can complete a real test (login, checkout, onboarding) in an actual browser. One runs a network request, the other runs the same steps a person would. You want both: uptime monitoring for server outages, smoke testing for functional failures the ping cannot see.
How do I know if my checkout is broken right now?
Run a smoke test. Open a browser, go to checkout, add an item, complete the test with a test card, and confirm the order confirmation appears. If it passes, checkout works. If it fails, you know before a customer does. Automate it to run after every deploy and on a schedule.
What should I check beyond a 200 response?
Run your critical tests end to end after every deploy and on a recurring schedule: login, checkout, and your core action, in a real browser, confirming the real outcome (an order confirmation, a successful login, a rendered dashboard). A test that actually checks out will catch every failure mode a 200 check misses. Smoketest runs your critical tests in a real browser after every deploy and on a schedule. You describe the test the way you'd explain it to a teammate, and it tells you whether it passed before your customers find out it didn't. See how it works.
