Your monitor says up because it checks a simple page load, not a customer task. Test full browser transactions, cache behavior, content matches, and regional paths next.
Synthetic monitoring means scheduled automated checks that simulate visits to your site. Datadog Docs recommends browser tests that sign in, add items, and assert page content, as described in its getting started guide for synthetic monitoring. Those tests catch login, cart, and checkout failures that a 200 response hides.
Table of Contents
- Why does a 200 check miss checkout failures?
- Is cache serving a stale good page?
- Are only some customers affected?
- What should deeper checks assert?
- Why do user metrics still look bad after a fix?
Why does a 200 check miss checkout failures?
A health endpoint can return 200 while the actions buyers need still fail. Login can load, then sign-in, add-to-cart, payment, or order confirmation can break afterward.
Test the path a customer takes, not only the homepage. Run a full browser transaction that signs in, adds an item, opens cart and checkout, and checks for expected text on each page. In WordPress or Drupal, use a test account and test product so forms, sessions, and permissions run as a shopper sees them.
Is cache serving a stale good page?
A content delivery network can return a cached HIT while the origin is down or broken. Cloudflare Docs explains that Always Online can serve stale cache or an Internet Archive copy when the origin is unreachable, according to its Always Online cache documentation.
That paid stale page can make edge checks look healthy during an origin outage. Bypass cache for one test run, then compare cached and uncached responses for login, account, and checkout pages. Also confirm that dynamic HTML is not cached in a way that strips Set-Cookie, because Cloudflare Docs links that pattern to later redirects, 403s, 500s, and CSRF failures.
Are only some customers affected?
One passing location does not prove every customer path works. Dotcom-Monitor and Datadog Docs describe synthetic tests as controlled checks from chosen locations, so regional DNS, CDN points of presence, carriers, and firewalls can fail for some visitors only.
Ask affected customers for region, network, device, URL, time, and error text. Then rerun the same transaction from other regions, test direct DNS resolution, and check whether logged-in, mobile, and desktop paths behave differently. Field data from the Chrome UX Report can also disagree with lab runs because it reflects actual Chrome visits across devices, networks, and regions.
What should deeper checks assert?
Status alone misses expired certificates, DNS faults, missing content, and slow third-party code. Add DNS, SSL and TLS, keyword, and timing checks alongside HTTP checks, because Datadog Docs covers HTTP, SSL, DNS, TCP, WebSocket, and gRPC synthetic types. Use checks that prove the page is usable: Treat one blank page, missing button, or failed content match as a failure even when status is 200.
- assert a keyword or content match, such as product name, price, or order total
- validate certificate chain and expiry for the customer-facing host
- split timing into DNS, connect, TLS, first byte, and download
- block or test key third-party scripts to find one failing script that blanks the page
Why do user metrics still look bad after a fix?
Field data moves slower than your deploy. Google Chrome for Developers documents the Chrome UX Report as a 28-day rolling average of actual Chrome visits, updated daily, as explained in its CrUX API documentation.
That average needs eligible traffic volume and keeps old slow visits in the window after repair. Add first-party real-user monitoring with Navigation Timing and the web-vitals library for immediate per-page and per-region diagnosis.
