Skip to main content
Card class: HeroCategory: Monitoring
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.
What it countsThe pass/fail status of the most recent run of every Synthetic monitor tagged critical_path: true. The card returns one row per monitor with state green (last run succeeded), amber (degraded, completed but exceeded SLA), or red (failed).
NerdGraph endpointNRQL via NerdGraph: SELECT latest(result), latest(executionDuration) FROM SyntheticCheck WHERE tags.critical_path = 'true' SINCE 15 MINUTES AGO FACET monitorName. The SyntheticCheck event is emitted by every Synthetic run.
Metric basisResult of the most recent execution, not a windowed aggregate. Synthetic monitors run on a configured frequency (1, 5, 10, 15 minutes); the card polls the latest result for each.
Aggregation windowReal-time per monitor. The slowest-running monitor in the set determines the worst-case freshness. With a 5-minute monitor frequency the card data is at most 5 minutes old.
Severity thresholdAll critical-path monitors equally weighted. Any single red flips the card to red. Amber (SLA breach without failure) is a warning state, not an alert state.
Filtered hosts / servicesAll monitors tagged critical_path: true. The tag is set per-monitor in NR’s Synthetic UI; standard set: login, browse-category, product-detail, add-to-cart, checkout-start, payment-confirm.
Browser vs APM scopeSynthetic monitors run from NR’s global probe locations (a fleet of cloud machines); they exercise the customer-facing URLs externally. Different from APM (which instruments your servers from inside) and Browser RUM (which measures real users). Synthetics catch outages even when no real customer is shopping.
Sample basisNot sampled. Every run produces one SyntheticCheck event regardless of account ingest sampling.
Time zoneLast-run timestamps are UTC in NerdGraph; displayed in account timezone in NR UI.
Time windowRT
Alert triggerany failing (any monitor in red state). Amber states do not page but are visible.
Rolesowner, engineering, operations

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 tagged critical_path: true, each running every 5 minutes from London, Frankfurt, Virginia, and Sydney probes. The card view at 03:47 on 02 May 26:
MonitorLondonFrankfurtVirginiaSydneyCard state
login-with-saved-cardgreengreengreengreengreen
browse-category-womengreengreengreengreengreen
product-detail-loadgreengreenredgreenred
add-to-cartgreengreenredgreenred
checkout-startgreengreengreengreengreen
payment-confirm-test-cardgreengreengreengreengreen
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.
The duty engineer sees this card go red and immediately knows: (a) it’s US-East-only, (b) it’s at PDP, not earlier, (c) login still works so it’s not an auth issue. The card has compressed an investigation that would otherwise take 5, 10 minutes of dashboard navigation into 30 seconds. If this had been a global outage (all four probes red on all six monitors), the card flipping to red would correspond to roughly 100% of conversions blocked, and the conversation moves from “investigate” to “page the on-call CTO”. When the Virginia incident resolves at 04:01 (CDN cache flushed, edge POP recovered), the card flips back to green within one monitor cycle (5 minutes max).

Sibling cards merchants should reference together

CardWhy pair it with Critical-Path Tests Status
Synthetic UptimeAggregate uptime across all monitors (not just critical path). Useful for SLA reporting; this card is for live ops.
Uptime by RegionGeographic breakdown when this card goes red. Tells you whether one probe location or many are failing.
Browser Test Latency p95Browser-script monitors record a duration. p95 of these is the synthetic-side counterpart to RUM p95.
API Monitor Failures (24h)Subset focused on API-only Synthetic monitors. When critical-path includes both UI and API, this drills into the API half.
Operational Health ScoreComposite parent. A red critical-path card typically drives a 5, 10 point drop in the score via downstream Apdex / error-rate impact.
Datadog Synthetic Critical PathCross-connector peer. If both connectors run synthetic monitors against the same URLs, results should match.
Shopify Sales / MinRevenue-side outcome. A critical-path failure usually shows in sales/min within 2, 5 minutes as the affected funnel-step blocks customers.
GA4 Conversion RateCustomer-side outcome. Conversion drop during a critical-path red typically lags by 5, 10 minutes (GA4’s session attribution window).

Reconciling against the vendor’s own dashboard

Where to look in New Relic: Why our number may legitimately differ from New Relic’s own screens:
ReasonDirection of divergence
Sync cadence. Vortex IQ syncs every 30s; NR’s Synthetics UI is real-time. Single-run flutter (a probe blip that resolves before next run) may not appear in Vortex IQ.Vortex IQ may miss isolated transient failures
Account timezone vs UTC. Last-run timestamps are UTC in Vortex IQ; account-timezone in NR UI. Doesn’t affect status, only displayed timestamps.Display only
NRQL retention. SyntheticCheck events retain 13 months on standard plans. The card always uses SINCE 15 MINUTES AGO so retention is not a concern; longer historical queries (uptime trends) may use rolled aggregates.None for live status
NerdGraph rate limits. Default 3,000 points / minute / account. Synthetic queries are cheap; rate-limiting only relevant during heavy investigation.Stale, not wrong
Tag scope. Vortex IQ filters tags.critical_path = 'true'. If a merchant updates the tag set without re-syncing, the card may show monitors that have been retagged. Reconnect the integration to refresh tag scope.Either direction; resolved by reconnect
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 on Transaction 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 25,25, 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.

Tracked live in Vortex IQ Nerve Centre

Critical-Path Tests Status is one of hundreds of KPI pulses Vortex IQ tracks across New Relic and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.