At a glance
The percentage of requests served by your instrumented services that returned an error response (HTTP 5xx, RPC error, span status error). For a merchant, this is “of every 100 shoppers who tried to do something on my site in the last hour, how many hit a broken page?” Above 1% means real customers are seeing real errors; above 5% means revenue is leaking right now.
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 US apparel brand on BigCommerce with Datadog APM instrumented across web, checkout, search, and an inventory worker. The error rate sat at 0.4% steady-state through 03 Apr 26 then jumped during a deploy at 14:00 GMT.
Apdex dropped from 0.92 to 0.87 during this 6-hour window. Conversion rate dropped 18% in the same window. The 18:00 recovery in error rate matched a recovery in BigCommerce orders/min from 12 to 41 within 25 minutes.
- Error rate above 2% sustained for more than 5 minutes is always a paging event. No matter how confident the engineering team is in the deploy, the cost of a false positive (an unnecessary page) is dwarfed by the cost of letting a real regression run another 30 minutes.
- The error-rate curve and the orders/min curve are correlated but lagged. Shoppers do not abandon instantly; they retry, refresh, and try a different browser. The lag is typically 5-15 minutes for desktop and 2-8 minutes for mobile (mobile shoppers abandon faster). When you see error rate spike, expect the orders/min curve to dip 10 minutes later.
- Rollback is faster than fix-forward. The team rolled back at 16:45 and the error rate normalised by 17:00. If they had tried to debug-and-patch in production, the incident would likely have run another 90 minutes. Internalise this: at error rates above 2%, rollback first, debug after.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Datadog:APM → Service List for per-service error-rate breakdown. APM → Traces to drill into individual error spans for a specific time window. Dashboards → APM Overview for the time-series chart showing the rolling error rate. Monitors → Manage Monitors to see which alert is wired to this metric and what threshold is active.Why our number may legitimately differ from Datadog’s UI:
Cross-connector reconciliation:
Known limitations / merchant FAQs
My error rate is 0.4% and the alert says >2%. Why is the card amber? The card alerts on the rolling 5-minute average versus the 7-day baseline. If your steady-state is 0.05% and you have just risen to 0.4%, that is an 8x baseline jump even though the absolute rate is still low. The amber state catches changes, not just absolute thresholds. Open the Error Spike Detection card to see whether the jump is statistically significant. Datadog says everything is fine but customers are complaining about errors. This is the most common Datadog blind spot for ecommerce, and it is real. Three places to check, in order: (1) JS Errors / Session, browser-side errors do not appear in server-side APM; (2) Critical-Path Tests Status, if a synthetic checkout test is failing while APM looks fine, the regression is in a code path Datadog is not instrumenting (third-party script, payment iframe); (3) GA4 Property Health, browser-side measurement gaps. The classic cause: a third-party script (chat widget, review widget, paid-social pixel) starts throwing errors and Datadog APM has no visibility. Add Datadog RUM to catch this class of issue. What is the difference between an alert and an incident in this context? An alert (or “monitor triggered”) is a single threshold breach: a metric crossed a number for a period. An incident is a coordinated response: someone has acknowledged the alert and is actively investigating. Datadog uses both terms; Vortex IQ surfaces alerts on Alerts Summary and incidents on Active Incidents. The error rate metric drives alerts; humans declare incidents. Why does my error rate include 4xx errors? My team only considers 5xx errors as real. That depends on your APM instrumentation. By default, most Datadog tracers mark 5xx HTTP responses aserror:true but leave 4xx as error:false. If your team has overridden this (some teams mark 401/403 as errors to track auth issues), the rate will look higher than your “5xx only” mental model. Use 5xx Response Rate for the strict 5xx-only view.
My Logs API returns 400 No valid indexes. Does this card still work?
Yes. The error rate card is APM-derived, not log-derived. Vortex IQ logs the Log Management gating event once at INFO level and skips log-only cards (like Top Error Log Patterns and Error-level Log Rate), but the headline error rate, Apdex, latency, and incident cards continue to function normally.
Datadog has a 15-month retention; Vortex IQ shows me 7 days. Why?
Vortex IQ’s default rolling-window comparison is T/7D vsP because most actionable error-rate movements resolve in hours, not months. To see the longer view, use Apdex Trend for a 90-day picture, or query the underlying metric directly in Datadog with the date range you want. Vortex IQ stores its own historical snapshots for trend cards but does not duplicate Datadog’s 15-month metric store.
My account has multiple Datadog organizations (multi-account aggregation). How is the error rate computed?
Each Datadog organization is a separate Vortex IQ connector instance and produces its own error-rate card. The headline does not blend organizations; the Stacked Panel feature on the Nerve Centre lets you display three or more side-by-side. This is correct for most merchants because each organization typically corresponds to a different store, brand, or environment.
RUM error rate is much higher than APM error rate. Which one do I trust?
Both, and they measure different things. APM error rate is “of all traced requests, how many returned an error”. RUM error rate is “of all browser sessions, how many threw a JavaScript error”. RUM will always be higher because it includes third-party script failures, ad-blocker interference, and browser quirks that the server never sees. APM is the right metric for “is my code broken”; RUM is the right metric for “is the shopper experience broken”. They are complementary; merchant dashboards should show both.
Why does the error rate look fine during overnight hours when I know we had an incident?
At low-volume hours (under 1,000 spans/min) absolute error counts can stay in single digits even during a real degradation, which keeps the rate technically below the threshold. Vortex IQ flags these windows as “low-confidence” and uses absolute counts (>10 errors in any 5-minute window) as a secondary trigger. This catches overnight regressions that the rate alone would miss.