Login, browse, add-to-cart, checkout, the customer journey synthetics. Any failure = revenue at risk.
At a glance
The pass/fail status of the four critical customer-journey synthetic tests: login, browse, add to cart, checkout. For a merchant, this is “right now, can a real shopper complete the journey from arriving to paying?” Unlike aggregate uptime, this is a binary, real-time view: any test failing equals revenue at risk right now, not “over the past 30 days”.
Calculation
Calculated automatically from your Datadog data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK fashion brand on Shopify with Datadog Synthetics running 4 critical-path tests every 5 minutes from 3 regions (us-east, eu-west, ap-southeast). Snapshot taken on 26 Apr 26 at 10:42 GMT.
The dashboard headline reads “1 of 4 critical-path tests FAILING” with a red banner. Three things the merchant should read:
- The checkout test is failing in all three regions. This is not a regional CDN issue; it is a global problem. Single-region failures are usually CDN, peering, or DNS; all-region failures are usually code, database, or upstream-service issues. The blast radius is global.
- APM error rate is at baseline (0.4%). This is the critical Datadog blind spot: APM thinks everything is fine because shoppers cannot even reach the failing path in normal flow (the failure is in a JavaScript validation that runs before the form submit, so no server-side error is logged). Synthetic catches it; APM does not.
- The card is the only signal that fired in the first 8 minutes. No incident has been declared yet (no human has acknowledged); no APM alert is firing; the merchant dashboard would otherwise look healthy. This card is the only thing standing between the merchant and a 90-minute revenue gap that no one notices.
- This card is the highest-leverage signal in the Datadog manifest. It catches what APM, error rate, and incidents miss: customer-facing regressions in code paths the server never sees as broken. Every merchant should make this the first card they look at every morning.
- All-region failures are different from regional failures. All-region equals real code or upstream issue; single-region equals CDN, DNS, or peering. The triage path is different; the card breakdown surfaces the regional pattern.
- Tag your custom journeys. The default 4 (login, browse, add to cart, checkout) cover most merchants but if you have B2B portals, gift-card redemption, mobile-app deep links, or wholesale ordering, tag those tests
purpose:critical-pathand they appear here automatically. Do not assume “default” means “complete”.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Datadog:
Synthetic Monitoring → Tests filtered by tag purpose:critical-path.
Synthetic Monitoring → Test Results for individual run history with screenshots and step-by-step outcomes.
Synthetic Monitoring → Locations to confirm the regions tests are running from.
Why our state may legitimately differ from Datadog’s UI:
Cross-connector reconciliation:
Known limitations / merchant FAQs
Why does this card matter more than the aggregate Synthetic Uptime? The aggregate is a 30-day average across all tests; this card is the live state of the four customer-journey tests. A 99.7% aggregate looks great but can hide a checkout test that is failing right now. Read this card first every morning. Datadog says everything is fine but customers are emailing about checkout problems. This is the classic Datadog blind spot, and this card is designed to catch it. Server-side error rate, Apdex, and incidents may all show green when a customer-facing JavaScript validation is broken. Synthetic browser tests run the full journey including JS execution, so they catch what APM cannot. If this card is red while the rest is green, the failure is in a code path Datadog APM does not instrument (third-party widget, payment iframe, browser-only logic, custom JS). My checkout test is failing but customers are still placing orders. Is the test wrong? Possible causes: (1) The synthetic test uses a fake test card that triggers fraud rules in production (legitimate failure for the test, no impact on real shoppers); (2) The test runs from a Datadog IP range your WAF is blocking; (3) The test depends on a third-party service (analytics SDK, A/B test framework) that is intermittently slow on the test’s network; (4) The test’s selector targets an element that has changed in a recent UI deploy. Check the synthetic-result screenshots and step-by-step trace in the Datadog UI to diagnose. How do I add a custom critical-path test? In Datadog UI: Synthetic Monitoring → New Test → Browser Test (or Multistep API). Build the journey, add the tagpurpose:critical-path, and save. Vortex IQ picks it up within 1-2 polling cycles. Common additions for non-default critical paths: gift-card redemption, B2B portal login, mobile-app deep link, subscription signup, returns flow.
What test cadence should critical-path tests run at?
5 minutes is the right default. 1-minute tests are unnecessarily expensive (Datadog charges per run); 15-minute tests miss too much. The 5-minute cadence with a 5-minute confirmation window means a real failure gets paged within 10 minutes worst-case, which is fast enough to catch deploy regressions before significant revenue is lost.
My Logs API returns 400 No valid indexes. Does this card still work?
Yes. Synthetics is independent of Logs. The Vortex IQ engine logs the gating event once at INFO and continues serving Synthetics-API-derived cards normally.
Why does the test fail intermittently in one specific region?
Three usual causes: (1) The CDN’s POP in that region briefly degrades and your asset cache is incomplete; (2) The Datadog synthetic location is in a peering-degraded path to your origin; (3) Your origin’s per-region rate-limit kicks in. Mitigate by reducing test frequency from that region or whitelisting the Datadog synthetic IPs in your WAF / rate-limiter.
Can I exclude tests from this card without deleting them?
Yes. Three options: (1) Remove the purpose:critical-path tag from the test; (2) Mute the test in Datadog UI (the card excludes muted tests); (3) Pause the test entirely. Each has different implications: untagging keeps the test running but hides it; muting suppresses alerting but keeps visibility; pausing stops the test from running entirely (no historical data while paused).
The test passes from the synthetic but a real shopper from the same region complained.
Synthetic tests use a fixed device profile and network speed; real shoppers vary. A test that passes from a fast Datadog data-centre may fail from a real shopper’s mobile-3G network in a rural area. Pair with Page Load p95 (RUM) and Frustrated User Sessions to see real-shopper measurements in the same region. RUM catches what synthetic does not, and synthetic catches what RUM cannot (proactive detection when no shoppers are using the site).
Why are alerts treated as P1 even for non-checkout tests?
Because every customer-journey test is on a path that, when broken, causes shoppers to bounce. A failing login flow blocks repeat customers; a failing browse flow blocks discovery. The P1 treatment ensures these alerts are not deprioritised behind general monitor noise. Adjust per-test severity in Settings → Datadog → Critical-Path Severity if your business has different priorities (rare).