SLO and SLA: Alert and response procedure

Defines one user-journey SLO with burn-rate alerts, a feature-freeze when the error budget is exhausted, and exclusion of documented maintenance from the burn calculation.

Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.

Decision

Operate a single availability SLO for the documented user journey, not a pile of per-endpoint ratios. Page on fast and slow burn of remaining error budget. When the window’s budget is exhausted, freeze user-facing feature launches until budget replenishes or a recorded exception exists. Calendar-published maintenance is excluded from both good and bad counts. This is a shipping policy, not a marketing uptime claim.

Scope

• One journey, success predicate, window, and target ratio.
• Multi-window burn-rate alerts and the freeze after exhaustion.
• Who may declare maintenance and how it is excluded.
• Freeze as an input to user-facing API release trains.

Outside this block

• Liveness and readiness probe wiring.
• Canary abort math beyond consuming freeze state.
• Customer SLA credits.

Contract

• Exactly one SLO identifier is authoritative for freeze decisions on the named journey.
• A request is failed only when the profile success predicate is false; expected validation 4xx is not an SLO error.
• Fast-burn and slow-burn alerts fire when the profile multiples are exceeded on their windows.
• When remaining budget for window_days is zero, feature_freeze is true until budget is positive or an exception with owner and expiry exists.
• Events inside a published maintenance interval are omitted from both counts.
• Freeze does not block security patches or restoring rollbacks named in the profile.

Implementation

Export the journey from customer request telemetry with a stable SLO label. Compute budget as 1 - target times valid events, minus maintenance. Gate feature releases on freeze; keep patch and rollback pipelines open. Persist exceptions with actor, reason, and expiry.

Failure handling

If telemetry is down, treat budget as unknown and do not lift a freeze automatically. Do not rewrite historical burn for late-declared maintenance; file a restatement. Additional journeys need their own blocks. Page-worthy burn must reach a human.

Verification

Track remaining budget, freeze transitions, exceptions, and launches during freeze. A launch without an exception is a contract failure. Recalculate a known incident with and without the published interval. Execute the packaged scenarios on traffic fixtures.

The executable-looking examples in this package are fixtures and acceptance contracts. Run python tools/validate.py from the collection root to check package structure and metadata; then implement and execute the scenarios in the target repository.

Adoption assumptions

• Names and numeric values in example.yaml are an adoption profile, not universal defaults.
• The adopting team must map actors, data classes, error vocabulary, and ownership to its system.

References

• sre-error-budget