No burn anomaly

Reading time: 0 minute(s) (0 words)

The No burn anomaly identifies an SLO objective that has not consumed error budget for an unusually long time. Perfect or near-perfect reliability can be genuine, but it can also mean that an objective is too lenient or that its queries do not capture failures.

How detection works

Nobl9 observes the objective's instantaneous burn rate. A continuous sequence at or below the configured no-burn threshold starts the observation period. A burning point interrupts that sequence.

With the defaults, the anomaly is detected after eight weeks without burn. The default cooldown is zero, so a burning point resolves the open anomaly immediately.

No burn detectionThe burn rate remains at zero for eight weeks. A later burning point resolves the anomaly.

Instantaneous burn rate

Setting	Automatic default
Observation period	8 weeks
Cooldown	None

Healthy services can trigger this anomaly

Treat No burn as a prompt to validate the SLO, not as proof that the objective is misconfigured. A service with genuinely perfect performance can produce the same pattern.

Example

If an objective remains at 100% reliability for eight weeks, Nobl9 creates a No burn annotation. The annotation is resolved when the objective records burn again. A later uninterrupted no-burn period starts a new observation period.

What to investigate

For a threshold SLO, check whether the objective target is too lenient. For a ratio SLO, verify that the numerator and denominator do not count almost identical event sets and that failures are included in the total population.

Use SLI Analyzer to compare the configured objective with historical data. See Data anomaly troubleshooting for more checks.

API access

Query No burn anomalies with the Anomalies API and anomalyTypes: ["NoBurn"]. Retrieve continuously detected annotations with the Annotations API and category=NoBurnAnomaly.