> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # SLO Burn Rate (1h), Datadog > Multi-window burn-rate alerting, anything above 14.4× will eat the monthly budget in a day. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Monitoring](/nerve-centre/connectors#connectors-by-type) > 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. | | | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **API endpoint** | Datadog SLO API, `GET /api/v1/slo/{slo_id}/history` for the time-series, `GET /api/v1/slo` for the SLO definitions. Burn rate is computed by the engine from the time-series. | | **Metric basis** | Error budget consumption per hour divided by the steady-state consumption rate the SLO permits. Steady-state for a 99.9% SLO over 30 days is 0.1% errors / 720 hours = 0.00014% / hour. A 1-hour window of 0.001% errors is 7× burn. | | **Aggregation window** | 1-hour rolling window for the displayed value; multi-window alerting (1h + 5m, 6h + 30m) is configured server-side in Datadog. | | **Severity threshold** | P1 = above 14.4× (will exhaust 30-day budget in 24 hours); P2 = above 6× (alert trigger); P3 = above 3× (worth investigating). The 14.4× number comes from Google SRE: 100% / (24/720 × 100%) = 30, halved for safety = 14.4×. | | **Alert pre-filtering** | Synthetic test traffic and health-check endpoints excluded from SLO numerator/denominator at the SLO definition layer (configure in Datadog SLO query). | | **Log Management gating** | Not used. Burn rate is computed from APM and metric data underlying the SLO; the card returns valid values regardless of Logs status. | | **Why "burn rate" instead of "errors per hour"** | Burn rate normalises by your specific SLO target. A 99.9% SLO and a 99.99% SLO can both have the same raw error count yet very different burn rates because the budgets are 10x different. Burn rate makes the alert threshold portable across SLOs. | | **Multi-window alerting** | Datadog's recommended pattern: alert on (1h burn > 14.4× AND 5min burn > 14.4×) for fast-burn pages, (6h burn > 6× AND 30min burn > 6×) for slow-burn pages. Vortex IQ surfaces the 1h burn here; the multi-window logic is in Datadog. | | **Filtered hosts / services** | The headline displays the highest burn-rate SLO across the account. Per-SLO breakdown lives on the table view. | | **Time zone** | Account timezone for chart axes; UTC for cross-connector windowing. | | **Time window** | `1H` (rolling 1-hour burn rate) | | **Alert trigger** | `> 14.4× (fast burn)`, will exhaust monthly budget in 24 hours; pages on-call. | | **Roles** | owner, engineering | ## 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. | SLO | 30-day target | Current 30-day | Budget remaining | 1h burn rate | What it means | | -------- | ------------- | -------------- | ---------------- | ------------ | -------------------------------------- | | SLO-CHK | 99.9% | 99.94% | 67% remaining | **17.2×** | Will breach in 19 hours at this rate | | SLO-SRCH | 99.5% | 99.42% | 12% remaining | 3.1× | Slow-bleed, watch but no urgent action | 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. ```text theme={null} Calculation example for SLO-CHK: - 30-day target: 99.9% - Allowed error rate: 0.1% - Allowed errors per hour at steady-state: 0.1% / 720 hours = 0.000139% - Observed errors in last hour: 0.00239% (17.2× the steady-state) - At this rate, monthly budget consumed in: 720 / 17.2 = 42 hours - Already consumed 33% of budget in 8 days (steady-state would be 27%) - Days until breach if rate continues: 7-8 days ``` 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 | Card | Why pair it with SLO Burn Rate | What the combination tells you | | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | [Error Budget Remaining](/nerve-centre/kpi-cards/datadog/error-budget-remaining) | The accumulated counterpart of burn rate. | Burn rate plus budget remaining tells you days until breach. | | [SLO Compliance (current period)](/nerve-centre/kpi-cards/datadog/slo-compliance) | The SLO's current period state. | Compliance dropping plus high burn rate equals "actively breaching"; compliance OK plus high burn rate equals "will breach if rate continues". | | [Days Until SLO Breach (forecast)](/nerve-centre/kpi-cards/datadog/days-until-slo-breach) | The forecast: at this rate, when does the SLO breach? | Forecast under 7 days plus high burn rate equals page; forecast 30+ days plus low burn rate equals safe. | | [Error Rate](/nerve-centre/kpi-cards/datadog/error-rate) | The driver of burn-rate spikes for error-based SLOs. | Error rate spike plus burn rate spike equals "the cause is server-side errors". | | [p95 Response Time](/nerve-centre/kpi-cards/datadog/p95-response-time) | The driver for latency-based SLOs. | Latency spike plus burn rate spike on a latency SLO equals "the cause is latency degradation". | | [Operational Health Score](/nerve-centre/kpi-cards/datadog/operational-health-score) | The composite that includes SLO compliance as a 25%-weight component. | Composite drop plus high burn rate equals "the SLO degradation is dragging the composite". | | [Active Incidents](/nerve-centre/kpi-cards/datadog/active-incidents) | A high burn rate without an open incident is the surface to action. | Burn rate plus zero incidents equals "engineering has not declared this is real yet". | | [Shopify / BC / Adobe Total Revenue](/nerve-centre/kpi-cards/shopify/total-revenue) | The merchant-impact peer. | Sustained high burn on a customer-path SLO typically corresponds to revenue dip. | ## Reconciling against the vendor's own dashboard **Where to look in Datadog:** > **[SLO List](https://app.datadoghq.com/slo)** for the master list with per-SLO burn rate and budget remaining. > **[SLO Detail (any SLO)](https://app.datadoghq.com/slo)** for the time-series of compliance and burn rate. > **[Monitors → SLO Alert Templates](https://app.datadoghq.com/monitors/manage)** for the multi-window burn-rate alerts. **Why our number may legitimately differ from Datadog's UI:** | Reason | Direction | Why | | ---------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Time zone** | Period-boundary effects | SLOs are defined over rolling 30-day windows in account timezone; Vortex IQ uses UTC for cross-connector arithmetic. | | **API rate limits** | Brief gaps | The SLO API is rate-limited; cached values may be 2-5 minutes stale. | | **Log indexing latency** | Affects log-based SLOs only | If your SLO query is log-based and Logs is gated, the SLO will read stale data. APM/metric-based SLOs are unaffected. | | **SLO calculation lag** | 5-15 minutes | Datadog computes SLO compliance on a 5-minute schedule; sub-15-minute movements may trail. | | **Highest-burn aggregation** | Either | Vortex IQ surfaces the *highest* burn rate across all SLOs as the headline; Datadog UI shows per-SLO views. The numbers match per-SLO; the headline is by design "the worst SLO right now". | **Cross-connector reconciliation:** | Card | Expected relationship | What causes the divergence | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Datadog APM error rate / latency | The driver: SLOs are computed from APM metrics. Burn rate spikes follow APM spikes by 5-15 minutes. | A burn-rate spike without an APM spike means the SLO is consuming budget from a different source (log-based SLO, synthetic-based SLO). | | [`shopify.total_revenue`](/nerve-centre/kpi-cards/shopify/total-revenue) / [`bigcommerce.total_revenue`](/nerve-centre/kpi-cards/bigcommerce/total-revenue) / [`adobe_commerce.total_revenue`](/nerve-centre/kpi-cards/adobe-commerce/total-revenue) | Sustained high burn on customer-facing SLOs typically corresponds to revenue dip. | High burn on internal-service SLOs (worker, batch, admin) does not correspond to revenue dip and is correctly excluded from merchant-impact alerting if you tag those SLOs `customer_facing:false`. | | Stripe / PayPal Payment Health | When a payment-PSP outage drives 5xx, both Datadog burn rate and payment-health-score drop. | Independent peers both confirming equals high-confidence real incident; only one moving equals investigate one side. |
Documentation cross-reference (same-concept peer) SLO burn rate is a Google SRE concept implemented by every major observability platform. This is **not** a reconciliation; your Datadog account does not have a parallel New Relic SLO instance to compare against. These references exist purely so an agency running clients on multiple monitoring stacks can cross-link the same metric across docs. * New Relic equivalent: SLO burn-rate alert via NerdGraph. * Honeycomb equivalent: SLO burn rate via SLO API. * Google Cloud Monitoring equivalent: SLO burn-rate metric.
## 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](/nerve-centre/kpi-cards/datadog/error-rate) or [p95 Response Time](/nerve-centre/kpi-cards/datadog/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](/nerve-centre/kpi-cards/datadog/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](/nerve-centre/kpi-cards/datadog/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.