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”.
| API endpoint | Datadog Synthetics API, GET /api/v1/synthetics/tests filtered by tag purpose:critical-path. Live state from GET /api/v1/synthetics/tests/{public_id}/results/latest. |
| Metric basis | Latest run state (passed / failed / triggered) for each tagged critical-path test. The card displays a list of tests and their current state, NOT a 30-day aggregate. |
| Aggregation window | Real-time, refreshed every 60 seconds, with the latest run state as the displayed value. |
| Severity threshold | Each test failure is treated as P1 because the test represents a revenue-blocking journey. A failing checkout test alone is grounds to declare an incident. |
| Alert pre-filtering | Tests must be tagged purpose:critical-path to appear here. Tests tagged [DRAFT] or muted excluded. |
| Log Management gating | Not used. Synthetic results are pulled from the Synthetics API. |
| Which tests are critical | The default merchant manifest includes: (1) Login flow (sign-in succeeds, account dashboard loads), (2) Browse flow (homepage to category to product detail), (3) Add to cart flow (PDP to cart to cart contents correct), (4) Checkout flow (cart to checkout to fake-card payment to confirmation page). Add custom journeys (gift-card redemption, B2B login, mobile-app deep link) by tagging purpose:critical-path. |
| Why this card matters more than the aggregate | A 99.7% aggregate uptime can hide a checkout test that is failing right now. The aggregate is a 30-day average; the critical-path view is the live state. A merchant’s morning routine should be: glance at this card first, then everything else. |
| Filtered hosts / services | All tests in the connected Datadog account tagged purpose:critical-path. |
| Time zone | Account timezone for “last run at” timestamps; UTC for cross-connector arithmetic. |
| Time window | RT (real-time, last run state) |
| Alert trigger | any failing, any single critical-path test failing pages on-call. |
| Roles | owner, engineering, operations |
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.| Test | Last run | Status | Last failure | Region of failure |
|---|---|---|---|---|
| Login flow | 10:40 | Pass | 21 Apr 14:20 | eu-west (intermittent) |
| Browse flow | 10:42 | Pass | 19 Apr 09:15 | ap-southeast (CDN) |
| Add to cart flow | 10:41 | Pass | 22 Apr 11:30 | eu-west (transient) |
| Checkout flow | 10:39 | FAIL | 26 Apr 09:45 (now) | All three regions |
- 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
| Card | Why pair it with Critical-Path Tests Status | What the combination tells you |
|---|---|---|
| Synthetic Uptime | The aggregate view across all synthetic tests. | Aggregate green plus critical-path red equals “the easy tests pass; the customer journey fails”. |
| Uptime by Region | Per-region breakdown. | All-region failures equal global cause; single-region equal CDN/DNS/peering. |
| Browser Test Latency p95 | Latency view of the same browser tests. | Failure preceded by latency creep equals timeout-driven; sudden failure equals assertion-driven. |
| Operational Health Score | The composite engineering view. | Composite green plus critical-path red equals “Datadog APM does not see what the customer sees”. |
| Active Incidents | The human-declared peer. | Critical-path red plus zero incidents equals “engineering has not noticed”. |
| Revenue at Risk (live) | The financial reframing. | Once an incident is declared from a critical-path failure, this card translates “checkout broken” into “£X,XXX/hour leaking”. |
| Conversion Drop During Incidents | The post-incident measurement. | Critical-path failure plus measured conversion drop equals confirmed customer impact. |
| Shopify / BC / Adobe Total Revenue | The truth-side metric. | Critical-path red plus revenue stable equals “synthetic test is misconfigured (false negative)”; critical-path red plus revenue drop equals real customer loss. |
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:
| Reason | Direction | Why |
|---|---|---|
| Time zone | ”Last run at” timestamps shift | Datadog UI displays in account timezone; Vortex IQ stores UTC. |
| API rate limits | Brief gaps | The Synthetics latest-result API is rate-limited; cached values may be 1-2 minutes stale. |
| Log indexing latency | Not applicable | Synthetics is independent of Logs. |
| Monitor state cache | Up to 60 seconds | Synthetic test results take up to 60 seconds to propagate from run completion to API surface. |
| Tag filtering | Vortex IQ stricter | Vortex IQ requires purpose:critical-path tag explicitly; Datadog UI shows all tests. |
| Card | Expected relationship | What causes the divergence |
|---|---|---|
google_analytics.ga_property_health | Independent measurement-side health peer. RUM client-side vs APM server-side discrepancy is healthy and expected; synthetic sits between the two layers. | Critical-path red plus GA4 amber equals “site is broken AND analytics is broken simultaneously”; rare but happens during severe deploy regressions. |
shopify.total_revenue / bigcommerce.total_revenue / adobe_commerce.total_revenue | Critical-path failure typically corresponds to revenue dip within 10-30 minutes for the affected journey. | Failure with no revenue dip equals “synthetic test is misconfigured” (most commonly: a fake-card payment not configured correctly, so it always passes in production but the synthetic still flags). |
| Datadog APM error rate | Decoupled: APM measures server-side, synthetic measures journey completion. RUM client-side vs APM server-side discrepancy is healthy and expected. | Critical-path red plus APM green is the most informative pattern: it catches problems APM cannot see (third-party widgets, payment iframes, JS validation logic). |
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).