Skip to main content
Metrics type: Key Metrics • Category: Monitoring
Multi-window burn-rate alerting, anything above 14.4x will eat the monthly budget in a day.

​
At a glance

The rate at which you’re consuming your error budget, expressed as a multiple of the budget-spend-rate that would land you exactly at the SLO target by month-end. 1x = on-track, 14.4x = monthly budget burns in a day, 36x = daily budget burns in 40 minutes. The Google SRE-style fast-burn signal that tells you whether you can afford another minute of degradation.

​
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 merchant has configured an SLO on the checkout-api service: 99.9% availability, measured as the ratio of non-5xx responses to total responses over a rolling 30-day window. The 30-day error budget = 0.1% x total_requests. With ~12M checkout requests/month, the budget = 12,000 errors. Reading the card at three points across an evening: What 14.4x actually means. The 30-day budget is 0.1% of all requests. A burn rate of 14.4x over the past hour means 1.44% of requests in that hour failed, 14.4 times the rate the budget allows. If sustained for 24 hours: 14.4 x 0.1% x 12M / 30 days = 14.4 x 12,000 / 30 = 5,760 errors/day = 169,560 errors over 30 days, far above the 12,000 budget. The alert fires because the trajectory if the current rate continues is unrecoverable. Why the multi-window check matters. A single bad 5-minute window can spike the 1h burn rate to 30x briefly even if the underlying 5m rate has already recovered. Multi-window alerting (must be >14.4x on both 5m and 1h before paging) prevents this kind of flutter. The Google SRE workbook recommends: Conversion impact translation. With error rate at 1.58% on checkout-api, ~158 customers per 10,000 requests are hitting a 5xx during checkout. At ~140 checkout requests / minute, that’s ~2.2 failed checkouts / minute, or ~133 / hour. At an average AOV of £85 and ~80% recovery probability (some customers retry), the irrecoverable revenue loss is 133 x £85 x 20% = £2,261 / hour. Sustained for 4 hours = ~£9,000 of GMV impact, plus reputational drag. The fast-burn alert is calibrated to fire well before this becomes catastrophic. If the underlying issue resolves and the next 1h window settles to 0.4% error rate, the burn rate drops to 4x, still over budget but no longer fast-burn. The card returns to green when the 1h burn drops below 1x; until then the message is “you’re spending faster than you can rebuild”.

​
Sibling cards merchants should reference together

​
Reconciling against the vendor’s own dashboard

Where to look in New Relic:
  • Service Levels is the canonical screen. Each Service Level entity has a “Burn rate” tab that displays the same multi-window evaluation.
  • Alerts & AI > Conditions for the alert configuration that backs the 14.4x threshold.
  • Dashboards > “SLO overview” pre-built dashboard.
Why our number may legitimately differ from New Relic’s own screens: Cross-connector reconciliation: NR Service Levels and Datadog SLOs implement the same Google SRE-workbook math. Burn rate calculations should be identical if the SLI definitions and SLO targets are aligned. Disagreements are real signal, not noise. Common causes: (a) one platform is computing on a slightly different event population (NR includes background workers, DD doesn’t); (b) one platform’s SLI thresholds are different (NR latency SLI at 1500ms, DD at 1000ms); (c) lookback window differs (one is 1h, other is 30m). Audit SLI definitions if cross-platform parity matters. NR APM-based SLO and GA4-based real-user SLO will typically disagree by 1, 5x burn rate during incidents. APM SLO captures server-side; GA4 SLO captures customer-side. Both are legitimate; the gap reflects client-side overhead (CDN, browser, third-party scripts) that doesn’t appear in APM-instrumented Transaction events.

​
Known limitations / merchant FAQs

NR vs Datadog: which SLO platform should I use? Either implements the same SRE-workbook math correctly. NR Service Levels has slightly cleaner UX for defining SLIs against existing APM Transaction events; Datadog SLOs has tighter integration with their Monitors product. Many teams use whichever lives closer to their primary observability platform; running peer SLOs on both is overkill unless you specifically need the cross-platform redundancy. Apdex math: how does Apdex relate to SLO? Apdex is one possible SLI input, not the SLO itself. You can define an SLO as “Apdex > 0.85 for 99% of 5-minute windows” and the burn rate will track that SLI. More common is a raw latency SLI (“p95 < 1500ms”) which is easier to alert on and reason about. Apdex and SLO are complementary: Apdex tells you the satisfaction state right now; SLO tells you whether you can afford another minute of bad satisfaction. NRQL retention vs SLO retention: how far back can I see burn rate? Burn rate evaluates a rolling 1h window, well inside the 8-day full-resolution NRQL retention. Historical burn-rate trend over 30+ days uses NR’s pre-rolled SLO storage (separate from raw event retention). So 90-day burn-rate history works on standard plans. Why does my NR burn rate disagree with Datadog by 0.4x? Almost always an SLI definition mismatch. The most common: NR’s SLI counts 4xx as “bad” while DD’s counts only 5xx, or NR’s SLI uses 1500ms latency threshold while DD uses 1000ms. Audit the SLI definitions on each platform; once aligned, burn rate should match within 5%. Sampling: does sampling affect burn rate? No. Burn rate is a ratio (bad events / total events) and NR’s sample-correction preserves the ratio. The absolute counts may differ from raw logs but the rate stays accurate. SLO compliance and burn rate are unaffected. Multi-account: I have a US and EU NR account, can I aggregate burn rate? Burn rates don’t aggregate by simple averaging because each may have a different SLO target. Connect each account separately and stack the cards. The Nerve Centre stack panel shows side-by-side burn rates rather than averaging, which is mathematically correct. Ingest cost vs visibility: SLOs require dense event data, can I sample down? Yes. The SLO compliance and burn rate calculations are sample-corrected, so dropping sample rate to 25% on non-critical-path transactions doesn’t break SLO accuracy. Keep critical-path (checkout, payment) at 100% to maximise sensitivity. Standard recommendation: 100% checkout, 25% browse, 100% errors. Alert tuning: my fast-burn alert fires for 5 minutes then quiets, what’s happening? The multi-window check (must breach on both 5m and 1h) typically prevents this kind of flutter. If you’re seeing it, check: (a) whether the alert is configured single-window (simpler but flutter-prone); (b) whether your SLI definition catches a transient that doesn’t matter (e.g., a deploy retry storm). Move to multi-window alerting following the Google SRE workbook recipe. My burn rate is 50x but error rate is only 0.5%, how? Your SLO target is very aggressive. A 50x burn at 0.5% error rate implies your allowable rate is 0.01%, which corresponds to a 99.99% (four-nines) SLO. That’s an unusual target for commerce; most stores configure 99.9% (three-nines) where 0.5% error rate produces a 5x burn. Check the Service Level entity’s target value; lowering the target relaxes the burn-rate sensitivity proportionally.

​
Tracked live in Vortex IQ Nerve Centre

SLO Burn Rate (1h) 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.