Login, browse, add-to-cart, checkout, the customer journey synthetics. Any failure = revenue at risk.
At a glance
A traffic-light list of New Relic Synthetic monitors tagged as critical-path: login, browse-category, product-detail-view, add-to-cart, checkout, payment-confirm. Any single failure means a step in the customer journey is broken right now, and revenue is at risk before a real customer reports it.
Calculation
Calculated automatically from your New Relic 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 multi-region Shopify Plus store with six Synthetic monitors taggedcritical_path: true, each running every 5 minutes from London, Frankfurt, Virginia, and Sydney probes. The card view at 03:47 on 02 May 26:
Two monitors are red, both from the Virginia probe. London / Frankfurt / Sydney are passing. Reading: the customer-facing US-East region is having a problem at the product-detail and add-to-cart steps. The fact that other probes pass tells you it’s regional, not site-wide. The fact that login and browse-category pass tells you it’s PDP-specific (likely a CDN issue or an origin failure on a single edge POP).
Conversion impact translation. US-East serves roughly 35% of customers for this brand. With PDP and add-to-cart broken in that region:
- Affected traffic: 35% of total = ~140 sessions/min during peak.
- Funnel impact: PDP failure stops product browsing (loses ~70% of sessions); add-to-cart failure stops cart-builds (loses the remaining ~30% even if PDP loaded from cache).
- Effective lost conversion: 140 x 0.70 = ~98 sessions/min that can’t proceed past browsing.
- Carts not built: 98 x 0.12 (browse-to-cart rate) = ~12 lost cart-adds/min.
- Average AOV: £85.
- Exposure: ~£1,020/min of risked GMV in US-East alone.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in New Relic:- Synthetics > Monitors is the canonical view. Filter by tag
critical_path: trueto match this card’s scope. - Synthetics > Monitor > Results shows individual run-by-run history per monitor including screenshots and HAR files.
- Dashboards > “Synthetics overview” pre-built.
- Alerts & AI > Conditions for the alert backing this card’s “any failing” trigger.
Cross-connector reconciliation:
NR Synthetics and Datadog Synthetics are independent monitor systems running independent probes. A merchant with both running peer monitors against the same URLs should see matching status during incidents. Disagreements are real signal, not noise. Common causes: (a) probe locations differ (NR has a Frankfurt probe, DD doesn’t, so DD misses an EU regional outage); (b) monitor frequency differs (NR runs every 5 min, DD every 1 min, so DD catches shorter blips); (c) script differences (one platform’s monitor exercises a different selector and so passes / fails on different conditions). Align scripts and frequencies if cross-platform parity matters.
NR Synthetic critical-path vs real-customer outcome (GA4 conversion rate, Shopify sales/min): Synthetic catches outages before real customers do (typically 1, 5 min lead time depending on monitor frequency). When this card goes red and the real-customer cards stay green for 5+ minutes, the lead time is doing exactly what it’s supposed to. When real-customer cards drop first and then this card flips red, your synthetic coverage is missing the failure mode (worth investigating which step the synthetics didn’t exercise).
Known limitations / merchant FAQs
NR vs Datadog: which Synthetics platform should I use for critical-path? Either works. The choice usually comes down to which platform owns more of your stack. NR Synthetic has slightly broader probe geography (16 public locations vs Datadog’s 19, both adequate for most merchants); Datadog has a richer scripting library for complex flows. Many teams run a minimum viable set on one and a more elaborate set on the other for redundancy. Apdex math: do Synthetic results affect Apdex? No. Apdex is computed onTransaction events from APM, not on SyntheticCheck. Synthetic monitors have their own duration field but it doesn’t feed Apdex. They’re complementary signals: Apdex tells you what real customers experienced; Synthetics tells you what a probe experienced. Both should be on your wall.
NRQL retention: how far back can I see Synthetic results?
13 months on standard plans (Synthetic events retain longer than Transaction events). The card uses SINCE 15 MINUTES AGO so retention isn’t a concern for live status; for trend analysis and SLA reporting the full 13-month history is available.
NR and Datadog disagree: NR shows red, DD shows green for the same URL, who’s right?
Both, on different scopes. The most common causes: (a) different probe locations exercised the URL (NR’s Virginia probe failed; DD doesn’t have a Virginia probe so it ran from Atlanta and passed); (b) monitor frequency mismatch (NR ran 30s ago and saw the failure; DD ran 90s ago when the URL was healthy); (c) script differs (one platform follows a redirect the other doesn’t). Compare run timestamps and probe locations to disambiguate.
Sampling: are Synthetic runs sampled?
No. Every monitor run produces one SyntheticCheck event regardless of account-level event sampling. The result you see is exact.
Multi-account: my US and EU NR accounts have separate Synthetic budgets, can I see one combined view?
Connect each account as a separate Vortex IQ integration and stack the cards in the Nerve Centre. Stack panels render the union of monitors across accounts; any single red flips the stacked card to red.
Ingest cost vs visibility: Synthetic minutes are billed separately, what’s the right cadence?
Critical-path: 5-minute frequency from 4 probe locations. Cheaper non-critical monitors: 15-minute frequency from 1, 2 locations. The 5-min critical cadence costs roughly 50/month per monitor on standard NR pricing and gives you 4-minute worst-case lead time before customers notice. Going to 1-minute frequency on critical-path is overkill for most stores (the cost grows 5x and the lead-time improvement is marginal because the alert evaluation itself takes 1, 2 minutes).
Alert tuning playbook: my alert fires every time a single probe location blips, how do I quiet it?
NR’s “Multi-location” alert condition lets you require N of M locations to fail before the alert fires. Set this to “2 of 4” for critical-path monitors and you’ll suppress single-probe blips without losing real outage detection. The card’s red state still surfaces single failures (so the duty engineer sees them) but the pager only fires on real impact.
My critical-path is green but real customers are reporting issues, what’s wrong?
Three usual causes: (a) the failure mode is for a customer state your script doesn’t exercise (logged-in vs anonymous, specific product variant, region-specific tax rules); (b) the failure is intermittent at a rate below the monitor frequency (e.g., 5% of requests fail, but your 5-min monitor needs to hit one of those 5% in its single-shot probe); (c) the failure is downstream of the page load (a slow API, a hanging Stripe redirect). Add a synthetic that exercises the specific path, or shift to script-based monitors that drive a real flow rather than single GETs.