Constant burn anomaly
The Constant burn anomaly identifies an SLO objective that continuously consumes error budget for an unusually long time. It can expose an objective that is too strict or an SLI that does not represent the intended user experience.
How detection works
Nobl9 observes the objective's instantaneous burn rate. A continuous sequence above the configured burn threshold starts the observation period. A point at or below the threshold interrupts the sequence.
With the defaults, the anomaly is detected after one week of uninterrupted burn. Once detected, it resolves after 30 minutes without another burning point. A new burning point during that cooldown extends the open anomaly.
| Setting | Automatic default |
|---|---|
| Burn threshold | 0 |
| Observation period | 1 week |
| Cooldown | 30 minutes |
A real incident can produce sustained burn. Compare the annotated period with service incidents and telemetry before changing the SLO.
Example
Suppose an objective burns continuously for seven days. Nobl9 creates one Constant burn annotation. If the burn stops for 20 minutes and then resumes, the annotation remains open because the 30-minute cooldown did not complete. If the objective stays below the burn threshold for the full cooldown, the annotation is resolved.
What to investigate
For a threshold SLO, check whether the objective target is too strict. For a ratio SLO, compare the numerator and denominator scopes and confirm that the target matches historical performance.
Use SLI Analyzer to evaluate alternative targets and queries. See Data anomaly troubleshooting for more checks.
API access
Query Constant burn anomalies with the Anomalies API
and anomalyTypes: ["ConstantBurn"]. Retrieve continuously detected annotations with
the Annotations API and
category=ConstantBurnAnomaly.