Error Rate, New Relic

Card class: Hero • Category: Monitoring

​

At a glance

Percentage of Transaction events that ended in an error in the rolling window. The fastest leading-edge signal of a deploy gone wrong, an upstream dependency crashing, or a database hitting connection-pool exhaustion. The card a duty engineer should pin to a second monitor.

​

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 storefront on Cloud Run is showing this card going from 0.6% to 4.1% between 14:05 and 14:20 on 02 May 26. The duty engineer pulls this card up first. What’s actually happening: at 14:08 a deploy went out to the catalogue service. The new build introduced a regression in the product-detail endpoint that returns 503 when SKU has more than 12 variants. About 8% of products meet that condition, so roughly 8% of product-detail page loads now fail. Conversion impact translation. With 12,800 transactions / 5 min and a 4.1% error rate, ~525 customers in 5 minutes hit a broken page. At an average product-detail-to-cart conversion of 12% and an AOV of £85, that’s 525 x 0.12 x £85 = £5,355 of cart-add value lost per 5-minute window, or roughly £1,070/min of risked GMV. If the rollback takes 25 minutes from alert to deploy, the total exposure is ~£26.7k for a single regression. The Apdex calibration interaction matters here: with t = 0.5s, errors that take 8s to surface (the 503 timeout) push customers into the frustrated bucket (4 x t = 2s, anything above is frustrated). So Apdex drops from 0.91 to 0.74 at the same time the error rate climbs. The composite Operational Health Score drops from 87 to 68, breaching its 70 alert threshold roughly 2 minutes before the error rate alone would. If the card stayed at 0.6%, the conversation would be different: 0.6% of 12,800 is 77 errors in 5 minutes. Most are background-worker timeouts and 404 from bot crawlers; the customer-facing impact is negligible. Same number, different story, hence the rule “look at trend not absolute level”.

​

Sibling cards merchants should reference together

​

Reconciling against the vendor’s own dashboard

Where to look in New Relic:

• APM > Application > Error analytics for the same NRQL chart in New Relic’s native UI.
• Dashboards > pre-built “Error analytics” dashboard.
• Alerts & AI > Conditions to see the alert configuration that backs this card’s threshold.

The chart in NR’s APM > Errors page should match Vortex IQ to 4 decimal places when both are on the same time-window. If they differ by more than 0.5% on the same window, check the timezone and appName filters. Why our number may legitimately differ from New Relic’s own screens: Cross-connector reconciliation: NR APM and Datadog APM instrument differently (NR APM agent vs DD trace agent). On the same Express.js or Rails app, the two error-rate numbers should agree within 0.3% during steady state. A 1%+ persistent gap usually means one platform is missing instrumentation on a sub-route (common with framework middleware order changes) or one has a different error-classification rule (NR counts noticeError() calls, DD counts unhandled exceptions plus configured 5xx).

​

Known limitations / merchant FAQs

New Relic and Datadog disagree on error rate by 1.2%, who’s right? Probably both, on different scopes. The most common cause is one platform instrumenting a route the other doesn’t (a server-sent-events endpoint, a websocket handler, a framework error filter that swallows exceptions before NR sees them). Pick a 5-minute window where the gap is largest and run both queries with the same appName filter; if the gap persists, audit each agent’s coverage. A persistent 1%+ gap on otherwise identical scope is rare and worth a support ticket on whichever platform looks anomalous. Why is my error rate 0% but my customers report errors? Three usual causes: (a) the errors are client-side JavaScript, not server-side, see JS Errors / Session; (b) the application is catching exceptions and not calling noticeError(), so APM never sees them, audit the framework’s error middleware; (c) the failure is a 4xx (validation, auth) which NR’s default config classifies as “expected” rather than “error”. Add error_collector.expected_classes overrides if 4xx represents real customer pain. My error rate jumps every Sunday at 02:00, is something broken? Almost certainly a scheduled background job. Check whether your APM scope includes transactionType = 'Other' (NR’s classification for non-web work). If yes, weekly batch jobs (DB cleanup, report generation) can produce concentrated error volume that doesn’t affect customers. Restrict the card to WHERE transactionType = 'Web' to filter background work out. Apdex math: how do errors interact with Apdex? Errors automatically count as frustrated in Apdex calculation regardless of duration. So a 200ms error is treated identically to an 8s timeout in the Apdex bucket assignment. This is why a sudden error-rate spike often drops Apdex below 0.5 even when latency p95 looks unchanged: the frustrated bucket fills with fast-failing requests. NR’s Apdex doc covers the rule. NRQL retention is 8 days but my error trend chart shows 30 days, how? NR rolls up Transaction data into hourly aggregates after the full-resolution retention window. The 30-day trend chart you see uses the rolled aggregates beyond day 8. Counts and rates remain accurate; what you lose is the ability to drill into a specific minute past day 8. Sampling: am I missing real errors? On accounts in event sampling, NR keeps a representative subset. Rates are sample-corrected so the percentage you see is accurate; the raw error count may be lower than what your server logs show. If you need raw counts (e.g., for billing reconciliation), pair this card with log-side counts from Error-level Log Rate, which is unaffected by event sampling. Multi-account: I have a US and EU NR account, can I see one combined number? Vortex IQ reads one NR account per integration. To see the combined number, connect both accounts as separate integrations and stack them in the Nerve Centre (the stack panels feature averages by transaction count, not arithmetic average, so the combined rate is correctly weighted). Ingest cost vs visibility tradeoff: is there a way to keep accuracy and reduce cost? Yes. Drop sample rate on non-checkout transactions to 25%, keep checkout at 100%, and keep all error events at 100% (errors should never be sampled, they’re rare enough that the cost saving is small). The error rate stays accurate (sample-corrected), checkout flow visibility stays full-fidelity, and ingest cost typically drops 40, 60%. Alert tuning playbook: my alert fires too often, what do I tune? Three levers in order of usefulness: (a) increase the threshold from 2% to 3% if your baseline noise floor is >1.5%; (b) add a duration clause (“must stay above 2% for 5 minutes”) to suppress flutter; (c) scope the alert to user-facing transactions only (WHERE transactionType = 'Web'). Avoid disabling the alert entirely, an oversensitive alert is fixable, an absent alert costs revenue.

---

​

Tracked live in Vortex IQ Nerve Centre

Error Rate 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.