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

​
At a glance

The rate at which the merchant is consuming their monthly error budget, expressed as a multiple of the sustainable rate. A burn rate of 1× means errors are happening at exactly the rate the SLO permits over the month; 14.4× means at this rate the entire month’s error budget will be consumed in a single day. For a merchant, this is “are we running through our acceptable-error allowance faster than we should?” Above 14.4× is an emergency; it predicts SLO breach within hours.

​
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 two Datadog SLOs:
  • SLO-CHK Checkout availability: 99.9% over 30 days. Budget: 43.2 minutes of unavailability per month.
  • SLO-SRCH Search latency below 800 ms p95: 99.5% over 30 days. Budget: 3.6 hours of breach per month.
Snapshot taken on 28 Apr 26 at 15:00 EST. The headline displays 17.2× with a P1 alert because the highest-burn-rate SLO is in fast-burn territory. Three observations the merchant should read:
  1. The checkout SLO is in fast-burn. A 17.2× burn rate over the next 24 hours would consume 24/720 × 17.2 = 57% of the entire monthly budget. The SLO has 67% remaining now; at 17.2× burn for 24 hours, only 10% would remain by tomorrow. Engineering must act now or risk breach within hours.
  2. The search SLO is in slow-bleed. 3.1× burn rate is concerning but not urgent: a deploy degraded latency slightly two days ago and 12% budget remains. Page on-call but with P3 severity. The team has time to plan a fix during normal hours rather than emergency-page someone.
  3. The two SLOs have very different action paths. Fast-burn (checkout) demands immediate rollback; slow-bleed (search) demands a planned investigation. Conflating them produces poor outcomes; reading them separately produces appropriate response.
Three takeaways merchants should remember:
  1. The 14.4× threshold is calibrated, not arbitrary. It comes from the Google SRE workbook: at 14.4×, an SLO over 30 days is consumed in 24 hours, which is the longest-but-still-actionable response window before breach. Below 14.4× = “you have time to plan a fix”; above = “fix now or accept the breach”.
  2. Burn rate makes alert thresholds portable. A 99.9% SLO and a 99.99% SLO can have the same raw error count but very different burn rates because the budgets are 10x different. Engineering teams running multiple SLOs at different targets benefit from this normalisation.
  3. Fast-burn vs slow-bleed need different responses. Fast-burn = “rollback now”; slow-bleed = “schedule a fix this sprint”. Mistaking one for the other produces either over-paging (treating slow-bleed as fast-burn) or under-paging (treating fast-burn as slow-bleed). Multi-window alerting is the standard practice that distinguishes them.

​
Sibling cards merchants should reference together

​
Reconciling against the vendor’s own dashboard

Where to look in Datadog:
SLO List for the master list with per-SLO burn rate and budget remaining. SLO Detail (any SLO) for the time-series of compliance and burn rate. Monitors → SLO Alert Templates for the multi-window burn-rate alerts.
Why our number may legitimately differ from Datadog’s UI: Cross-connector reconciliation:

​
Known limitations / merchant FAQs

I am a non-engineering owner. Why does this card matter to me? Because SLOs are the engineering team’s commitment to your business. A 99.9% checkout-availability SLO is the team saying “we promise checkout will work 99.9% of the time, and if it does not, we will treat that as a failure”. Burn rate is the live signal that the team is at risk of breaking that promise. When burn rate is high, it means the team will need to either fix the underlying problem or break the promise; either has implications for the business. The headline of this card is the merchant-readable “are we at risk of breaking our reliability commitments”. What is an SLO? A Service Level Objective. It is a target like “99.9% of checkout requests succeed” or “p95 search latency below 800 ms” measured over a window (typically 30 days). The SLO defines the line; the error budget is what is left between observed performance and the line; the burn rate is how fast you are consuming the error budget. Why is 14.4× the magic number? At a 14.4× burn rate, you will consume 100% of a 30-day error budget in 24 hours. The math: monthly hours = 720; 24 hours / 720 hours = 3.33% of the period; if you burn 100% of the budget in 3.33% of the time, you are burning at 30× the steady-state rate. Halve for safety = 14.4×. This is the Google SRE-recommended threshold for fast-burn alerting. What is “fast-burn” vs “slow-bleed”? Fast-burn is a high burn rate over a short window (1 hour at 14.4×); slow-bleed is a moderate burn rate over a longer window (6 hours at 6×). Fast-burn requires immediate action (rollback, escalate); slow-bleed requires planned action (schedule a fix this sprint). Multi-window alerting (1h+5min for fast, 6h+30min for slow) is the standard practice. My burn rate is 80×. Should I be panicking? Yes, but tactically. A burn rate of 80× means you will consume the entire 30-day budget in 720 / 80 = 9 hours. If the rate continues, you will breach the SLO before your team’s lunch break. The right response: (1) Identify the underlying cause via Error Rate or p95 Response Time; (2) Decide between rollback, hotfix, or accept-the-breach; (3) If rolling back, do it within 30 minutes; if accepting the breach, schedule the fix and update the post-mortem. Datadog Incident Management is not enabled. Does this card still work? Yes. SLO Burn Rate uses the Datadog SLO API, which is independent of Incident Management. SLOs are available on the Pro tier and above; if you are on free tier, SLOs cannot be created and the card displays “No SLOs configured”. My Logs API returns 400 No valid indexes. Does this affect burn rate? Only for log-based SLOs. APM-based and metric-based SLOs are unaffected. If your team has defined a log-based SLO (count of error logs / total logs), that SLO’s burn rate becomes unreliable when Logs is gated; APM and metric SLOs continue to function normally. Should I have one SLO or many? The Google SRE recommendation: one customer-facing SLO per critical journey (checkout availability, search latency, login success), each tied to revenue impact. Avoid SLOs on internal services unless they directly affect customer experience. Most merchants are well-served by 3-5 SLOs total. Why does the headline always show only the highest burn-rate SLO, not the sum? Because burn rates do not sum meaningfully across SLOs. A 17× burn on checkout and a 3× burn on search are different problems with different priorities; averaging or summing them obscures both. The headline is “the worst SLO right now”, and the per-SLO breakdown lives below in SLO Compliance. My team uses error budget policies. How does Vortex IQ surface those? Error budget policies (e.g. “no risky deploys when budget is below 50%”) are configured at the engineering process layer, not in metrics. Vortex IQ shows the burn rate and budget remaining; whether your team’s deploy-freeze policy kicks in is enforced by your own deploy tooling. Pair this card with Error Budget Remaining to drive policy decisions.

​
Tracked live in Vortex IQ Nerve Centre

SLO Burn Rate (1h) is one of hundreds of KPI pulses Vortex IQ tracks across Datadog 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.