Detection Service Levels and Error Budgets

A service level begins with the promised outcome

A detection service exists to support a decision within useful time. A service-level indicator is the measurement of one property of that service. A service-level objective is the target range for that indicator over a defined population and interval.

For example, the promise may be that privileged-change evidence reaches evaluation within ten minutes for covered tenants. The indicator measures qualifying events that meet that window; the objective states the acceptable proportion.

“The rule runs” is too weak because execution can succeed with missing sources or broken delivery. Begin at the consumer outcome, then identify the dependencies that make it possible.

The indicator needs exact population and time semantics

Define eligible events, entities, sources, exclusions, measurement point, event time, processing time, and treatment of late arrivals. A percentage without these rules can improve simply because failing populations vanished from the denominator.

Separate unavailable, delayed, and invalid evidence. They may affect the same consumer promise but require different owners and repairs. Segment tenants or platforms when independent failure is possible.

Measure from independent records where possible. If the same scheduler reports both execution and success, its failure can erase the evidence of failure.

An error budget makes reliability tradeoffs explicit

An error budget is the amount of failure permitted by the objective during its measurement window. If the target is 99.5 percent, the remaining 0.5 percent is not free failure; it is a boundary for governing change and operational risk.

Consumption should influence decisions. Rapid burn may pause risky deployments, increase review, or prioritize restoration. A healthy budget may permit experiments whose benefits justify bounded reliability risk.

Security consequence matters. Missing one critical population can be worse than many low-impact delays, so use separate objectives or weighted policy rather than letting a broad average hide concentration.

Dependencies need ownership and failure responses

Map each objective to sources, transport, schemas, enrichments, state, analytics, routing, and acknowledgement. Name an owner for the end-to-end promise and operational owners for the parts.

Define alert thresholds, escalation, consumer communication, and recovery verification before a breach. A service-level alert should describe the affected capability and population, not merely a technical component.

Use detection health monitoring to identify early degradation and silent failure. Health indicators explain why an objective is at risk; the objective explains why that risk matters.

Review the objective when the security need changes

An objective is a policy choice, not a law of nature. Review it when threat priority, consumer workflow, technology, population, or cost changes. Tightening a target without funding its dependencies produces ceremonial reliability.

Report actual performance, budget burn, concentrated failures, exclusions, incidents, and uncertainty. Do not reset history when a version changes unless the measurement contract genuinely changes, and explain any discontinuity.

The final conclusion should remain bounded: facts show measured service behavior; assessment says whether the consumer promise was met; uncertainty identifies missing telemetry or ambiguous eligibility. That structure keeps a reliability number from overstating security effectiveness.

Avoid copying availability targets from unrelated services. A batch analytic supporting next-day review and a containment alert needed within minutes serve different decisions. Their objectives, windows, and acceptable failures should differ. The right target follows consequence and workflow, not a universal aspiration to accumulate more nines.