Yes — a dashboard can be entirely green while your checkout is broken and taking no money. Google's SRE team is explicit that a failed request can be implicit: the book *Monitoring Distributed Systems* counts "an HTTP 200 success response, but coupled with the wrong content" as an error, which is exactly what a status-code check scores as healthy.
That gap matters most on ecommerce and lead-generation sites, where the revenue path runs through third-party payment scripts, browser JavaScript and caching layers that server-side monitoring never touches. The fix is not more dashboards. It is monitoring that watches the transaction from the user's side, and alerting that describes symptoms a customer would recognise.
Table of Contents
- Why a green status check proves almost nothing
- Synthetic checks and real user monitoring answer different questions
- The third-party script blind spot
- Abandonment noise hides the break
- Even good monitoring can watch a failure without naming it
- What to change this week
- Frequently Asked Questions
Why a green status check proves almost nothing
A basic uptime check requests a URL and reads the HTTP status code — the three-digit number the server returns, where 200 means "here is your page." That test confirms the server answered. It says nothing about whether the payment form rendered, whether the "Place order" button was wired up, or whether the card field loaded at all. Google's SRE guidance names four golden signals for a user-facing system — latency, traffic, errors and saturation — and recommends pairing internal white-box metrics with black-box monitoring that tests the system from outside.
The reason is structural: networks, caches and proxies sit between your application and the customer, and a failure in any of them leaves application dashboards untouched. On a typical wordpress or drupal store, that outside layer is crowded. A CDN, a full-page cache, a payment gateway's hosted fields and a tag manager all sit between the PHP that you monitor and the checkout the customer actually sees.
Synthetic checks and real user monitoring answer different questions
MDN draws the line clearly. Synthetic monitoring runs scripted transactions from controlled environments; Real User Monitoring (RUM) injects a script into the page and reports load and interaction data from actual visitors' machines.
MDN's own comparison notes that neither approach alone tells you both whether the flow is broken and who was hit by it. The practical division is worth memorising: Most teams have one and assume it covers the other. A synthetic script that only loads `/checkout` and asserts the page title will pass every time a payment iframe silently fails to load.
- **Synthetic** answers "can a checkout be completed right now?" It runs on a schedule, so it catches a total break within minutes even at 3am with no traffic.
- **RUM** answers "who is failing, on what browser, in what country?" It only sees failures that real people hit, so a bug affecting one payment method in one region shows up here and nowhere else.
- **Neither** replaces server logs for backend errors, and a synthetic script that stops before the real payment step is testing the page, not the purchase.
The third-party script blind spot
Checkout is the part of a site most likely to be running someone else's JavaScript, and that code is systematically under-reported by error tracking. Grafana's Frontend Observability documentation describes error fingerprinting that deliberately filters library frames out so only first-party code contributes to the grouping — sensible for noise reduction, but it can suppress the signal from a failing vendor script. Platform-level checkout telemetry usually has to be turned on deliberately.
Datadog's Shopify RUM integration converts Shopify's `ui_extension_errored` event — raised when a checkout UI extension crashes — into a RUM error tagged with the failing extension's name, target, type and owning app. Without that integration wired up, the crash happens in the customer's browser and leaves no server-side trace. The generalisable rule: if the failure happens after the HTML leaves your server, something running in the browser has to report it, and you have to have configured that thing on purpose.
Abandonment noise hides the break
Even a conversion dashboard can miss this, because the baseline failure rate is already enormous. Baymard Institute puts average documented cart abandonment at 70.22% across 50 studies, with mobile at 80.45% against desktop's 68.62%. Work through what that means for detection.
If seven in ten carts normally fail, a bug that breaks one payment method for one browser might move the daily rate from 70% to 74% — inside the range of a slow Tuesday, a paid-traffic mix shift, or a public holiday. The signal is real and the dashboard is statistically incapable of distinguishing it. Baymard's testing also puts the stakes plainly: the average large ecommerce site could gain a 35.26% conversion increase from better checkout design, which the institute scales to roughly $260B in recoverable US and EU orders. An undetected functional break compounds against a funnel that is already lossy by default.
Even good monitoring can watch a failure without naming it
Having the data is not the same as reading it correctly, and this is the limit worth being honest about. Cloudflare's postmortem of its September 12, 2025 dashboard and API outage — roughly an hour from 17:57 UTC — records that engineers saw an API usage increase but could not distinguish retries from new requests, which delayed identifying a dashboard retry loop as the cause. The remediation added retry-versus-new flags to API calls and capacity-threshold alerting.
Google SRE's alerting chapter pushes in the same direction by separating symptoms ("what is broken") from causes ("why"). It describes an internal case where metric-driven alerts did not correspond to user-facing errors, forcing a triage step on every paged incident; the fix was a library that hooked each application's framework to decide at request time whether an error had actually reached a user. Communication is the third failure mode. ThriveCart's July 3, 2026 postmortem states that a single database upgrade disrupted checkouts and that its incident communication was too slow — a status update had been prepared early but was held while the team waited on the provider's resolution estimate, rather than telling users the issue was ongoing.
What to change this week
None of this requires replatforming. It requires making the checkout itself the thing being measured.
Start with the order-volume alarm. It is the cheapest of these to build, it needs no browser instrumentation, and it is the one check that would have caught every failure mode described above.
- Write a synthetic check that completes a real transaction end to end, using a test card or a sandbox order, and assert on the confirmation page's content — not on a 200 status.
- Add RUM to the checkout pages specifically, so you can see browser, device and country breakdowns when conversion dips.
- Check whether your error tracker is filtering third-party frames, and add an explicit rule or integration for your payment and checkout scripts.
- Alert on symptoms customers would describe — "no completed orders in 30 minutes during normal trading hours" — rather than on CPU or error-rate thresholds alone.
- Write the incident update template before you need it, and agree that you publish "we are investigating" without waiting for a vendor's ETA.
Frequently Asked Questions
Does a 200 status code mean the page worked?
No. Google's SRE book counts a 200 response carrying the wrong content as an error. The status code confirms the server replied, not that the page functioned.
If I can only afford one addition, synthetic or RUM?
Synthetic, if you have low or uneven traffic — it tests on a schedule regardless of visitors. RUM, if you have steady volume and your failures are browser- or region-specific.
Will Google Analytics catch a broken checkout?
Only if the break is large. With average abandonment at 70.22% per Baymard, a partial failure sits inside normal daily variance on a conversion chart.
