At a glance
Count of currently open New Relic Alert incidents at CRITICAL or HIGH priority. The single number that answers “is anything actively broken right now?” Zero means quiet; anything above zero is a duty-engineer signal.
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 BigCommerce + Cloud Run storefront, monitored by New Relic across 8 services and 22 hosts. The card shows3 at 11:42 on 02 May 26.
The duty engineer expands the card and sees:
Three incidents, but Applied Intelligence has correlated them into one issue family because they share the
checkout-api entity and started within a 4-minute window. Reading: a single root cause is producing three symptom-incidents.
Conversion impact translation. checkout-api is the most revenue-critical path. With error rate at 5%+ and p95 over 2s, the customer experience on checkout is materially degraded. Mapping to revenue:
- Healthy checkout completion rate: ~62% of carts.
- During this incident: roughly 30% drop in completion (customers who hit a 5xx or wait >5s typically abandon).
- Affected customers: ~140/min in business-hours traffic.
- Lost completions: 140 x 0.62 x 0.30 = ~26 lost orders/min.
- Average checkout AOV: £95.
- Exposure: ~£2,470/min of risked GMV.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in New Relic:- Alerts & AI > Issues & Activity is the canonical screen. The “Open” filter shows the same set this card counts.
- Alerts & AI > Conditions for granular condition-level view (matches Currently Triggered Conditions more closely).
- Dashboards > “Incident overview” pre-built dashboard.
Cross-connector reconciliation:
NR Alerts and Datadog Monitors are independent alerting systems. A merchant with both connectors typically has peer alerts on each (the same condition wired to both platforms), so the active incident counts should track within +/- 1 most of the time. Persistent gaps of 3+ are diagnostic: the most common cause is one platform missing an alert that fires on the other (a recently-added Datadog monitor with no NR equivalent, or vice versa). Audit the alert inventory on both sides.
NR Alerts vs PagerDuty open-incidents: NR fires, PD escalates. PD count should equal NR count plus any alerts routed from other sources (e.g., status pages, log management tools). A NR open count of 3 with PD showing 5 is normal if 2 of the PD incidents come from non-NR sources; PD showing 1 when NR shows 3 is a routing problem (NR alerts not reaching PD).
Known limitations / merchant FAQs
NR vs Datadog: should I configure alerts on both? Yes if both are connected. Peer alerts give you redundancy when one platform’s alerting backend has an outage (rare, but it happens). The cost is alert-noise discipline: you must keep alert definitions in sync, or the two platforms drift apart and the comparison loses meaning. Apdex math: does an Apdex breach trigger an incident? Only if you’ve configured an Apdex condition. NR doesn’t auto-create incidents from low Apdex; you create a condition in Alerts that says “incident if Apdex < 0.7 for 5 minutes”. Many teams forget this and rely on error-rate / latency alerts alone, missing the satisfaction-weighted signal. We recommend at least one Apdex condition per critical service. NRQL retention vs incident retention: how long can I look back? NRQLTransaction data has 8-day full-resolution retention on standard plans. Incidents are first-class entities in NerdGraph and retained 13 months by default, regardless of the underlying event retention. So you can review incident history (this card’s count over time) for a year even when the raw data is rolled up.
NR and Datadog disagree: NR shows 3 incidents, DD shows 1, who’s right?
Both. The most common cause is alert-condition coverage difference. NR may have 3 separate conditions (error rate, latency, DB pool) all firing on the same root cause; DD may have a single composite condition that bundles those signals into one incident. Neither is wrong, the counting policy differs. Compare condition inventories; align them if a single-number reading across both platforms matters to you.
Sampling: are incidents sampled?
No. Incidents are first-class entities, every triggered condition produces exactly one incident regardless of event-stream sampling. Even on heavily-sampled accounts, the count is accurate.
Multi-account: I have a US and EU NR account, can I see one combined count?
Vortex IQ reads one NR account per integration. Connect each as a separate integration and stack the cards in the Nerve Centre, the stack panel sums correctly across accounts.
Ingest cost vs visibility tradeoff: do incident alerts cost ingest?
Alert evaluation runs against ingested events (Transaction, Logs, Infrastructure, etc.) so the underlying ingest cost matters, but the alerting layer itself is free on standard NR plans. Reducing ingest by sampling does NOT reduce alert accuracy if you’re alerting on rates (sample-corrected) rather than absolute counts. Avoid alerting on raw counts of sampled events; alert on the percentage instead.
Alert tuning playbook: my count flutters between 0 and 1 every few minutes, how do I quiet it?
The flutter source is almost always a single condition with a too-tight threshold. Open Recently Flapped Conditions to identify it. Three fixes in order: (a) add a for at least 3 minutes clause to the condition; (b) raise the threshold by 10, 20% if the baseline is in noise territory; (c) use NR’s adaptive baseline condition type instead of a fixed threshold (auto-tunes to the service’s normal behaviour).
One issue groups 5 incidents, does the count show 1 or 5?
- The card counts issues (the AI-grouped containers), not raw incidents. This matches how a duty engineer reads the alerting screen, one issue means one root cause to investigate, even if it surfaced through five different conditions. To see the raw count, use Alerts Firing.