Burn rate measures how fast a service consumes its error budget over a given time window. It expresses the ratio between the observed error rate and the maximum allowable error rate defined by a service level objective (SLO). Teams use it to detect reliability degradation early, before breaching agreed service targets.
How It Works
An SLO defines the acceptable level of reliability, such as 99.9% availability over 30 days. This target implies an error budget—the amount of failure tolerated during that period. For example, a 99.9% availability objective allows roughly 43 minutes of downtime per month.
Burn rate compares the current error rate to the error budget consumption rate. If a service is allowed 0.1% errors but is currently experiencing 0.2%, the burn rate is 2.0. This means the system is consuming its error budget twice as fast as planned. At that pace, the monthly budget would be exhausted in half the time.
Teams typically evaluate burn rate over multiple windows, such as 5 minutes and 1 hour. Short windows detect sudden spikes; longer windows identify sustained degradation. Alerting policies often combine both to reduce noise while maintaining fast detection. This multi-window approach is common in SRE practices and supported by modern observability platforms.
Why It Matters
Traditional threshold alerts trigger on raw metrics like latency or error percentage, often without context. Burn rate ties alerts directly to SLO impact. Instead of reacting to every spike, teams respond when reliability objectives are genuinely at risk.
This approach improves operational focus. Engineers prioritize incidents that threaten customer experience and contractual commitments. It also supports better release decisions, since aggressive changes can be evaluated against remaining error budget capacity.
Key Takeaway
Burn rate translates real-time reliability signals into actionable insight by showing how quickly your service is spending its error budget.