SLA, SLO and Error Budgets

• Define SLA vs SLO vs error budget precisely
• Write SLOs as measurable ratios over rolling windows (freshness, uptime)
• Use error budgets to decide when to ship vs stabilize

• A promise without a measurement is not an SLA, it's a hope — SLOs make it countable.
• Error budgets give engineering a rational rule for when to stop shipping and stabilize.
• Consumers get predictability: they can plan against a documented budget of failure.
• It converts abstract 'are we reliable?' into a number teams can review weekly.

You can spend the allowance (ship features) but when it's gone, spending stops until payday. Error budgets are the same: spend reliability on velocity, and when the budget's spent, stabilize until the window resets.

• Write the SLO: ratio over a rolling window: 'sli requests good / requests total'. For data: freshness — % of runs whose lag ≤ SLA; completeness — % of days where key columns ≥ threshold.
• SLA = pledge + consequences (business credits); SLO = the engineering target set tighter than SLA.
• Compute burn: breach-seconds/seconds in the window → the error budget is 1 − ratios.
• Act on burn: at 75% budget → pause feature work and stabilize; at 100% → mandated freeze.
• Review in a weekly SLO burn meeting: ratios, big burners, corrective actions to regenerate budget.
• Automate: dashboards/reports update daily so the budget is always current.

• A warehouse platform promises 99% freshness SLO; a week of 3h delays in the nightly run burns 40% of the monthly budget, triggering a stability sprint on the ingestion job.
• A real-time team sets an SLO of 99.5% of consumer-group-lag under 5 min; weekends often dip, and the budget dictates a weekend on-call presence.
• A marketing platform reports a quarterly 'SLO burn report' to stakeholders, so reliability is discussed as a number, not a vibe.

• Set SLOs tighter than SLA so you have margin before the legal promise is missed.
• Measure the SLI from the consumer's point of view (what they observe), not the producer's internals.
• Track burn on a rolling window (30 days) so past failures age out wholesomely.
• Make the error budget the release gate: ship until spent, then stabilize — a rule, not a feeling.

• SLA and SLO conflated into one number nobody can measure honestly.
• Measuring an SLO from platform metrics when consumers experience something different.
• An error budget nobody acts on — a number that is a mirror, not a lever.
• Budget with no reset or with stale data, so the 'budget' lies.

• Budget suddenly empty → compute burn from the SLI data, not the alarm count; correlate with the exact days of burn.
• Missed SLA but SLO green → the SLI measurement window or definition differs from the SLA pledge — align them.
• SLO green but users unhappy → measure at consumer observation point; platform-side metrics hide their reality.
• Rising burn trend → look at the big single burners in the weekly burn report; usually 1-2 runs dominate.