SLOs and error budgets for a commerce store

Part 1 of the Platform SRE series — reliability is a budget, not a feeling. See also magento2-observability.

Why this matters

Every commerce team agrees reliability matters until a campaign week arrives, and then every pending feature suddenly matters more. Without explicit Service Level Objectives, that argument is settled by whoever speaks loudest: engineering wants a deploy freeze, marketing wants the new promotion rule live, and leadership has no number to decide with. An SLO replaces the debate with arithmetic. It states which journeys must work, how often, and how fast, and the error budget derived from it states how much failure the team can afford before feature work stops.

For Magento this framing fits naturally. The store has a small number of journeys that directly produce revenue (browse, add to cart, checkout, pay) and a large number of supporting paths that do not. Treating all of them as equally critical guarantees either over-investment in low-value reliability or under-protection of checkout. SLOs force the ranking.

How it works

Three steps: pick the journeys, set objectives with teeth, and spend the budget by policy.

Measure journeys, not servers

An SLO should describe a shopper-visible outcome, expressed through Service Level Indicators that the store already emits or can emit cheaply. Good starting SLIs for Magento:

• Checkout success rate. Proportion of checkout sessions that reach order-placed without a 5xx, payment gateway timeout, or fatal JS error, measured from server access logs plus the payment callback stream.
• Add-to-cart availability. Proportion of add-to-cart POSTs returning 2xx within the latency bound, segmented by store view.
• Storefront latency. Proportion of cache-miss category and product page renders completing server-side under a threshold (for example 800ms at p95), measured at the Fastly/Varnish edge or the PHP access log, not from synthetic probes alone.
• Order pipeline freshness. Delay between order placement and ERP/OMS export acknowledgement, which catches the async failures shoppers never see but finance always does.

Server metrics (CPU, Redis memory, queue depth) remain essential for diagnosis, but they are not SLOs: a store can have green servers and a broken checkout when a payment API changes its contract. If the SLI does not follow the money, it does not belong in the SLO set.

Set objectives tight enough to bite

An SLO like 99.9 percent checkout success over a rolling 30 days sounds aggressive until converted into an error budget: 0.1 percent of checkouts allowed to fail, which on a store doing 10,000 checkouts a day is 10 failed checkouts a day, or about 43 minutes of full checkout outage per month. That number is small enough to protect revenue and large enough that normal deploy hiccups do not instantly exhaust it. Latency SLOs pair with it: 95 percent of uncached product renders under 800ms server-side, for instance, keeps the merchandising team honest about block weight.

Price the budget in revenue per minute so the business reads it directly. If peak-hour revenue runs $2,000 per minute, a 30-minute checkout outage costs roughly $60,000 in deferred or lost orders, and the remaining budget at any point in the window is expressible as minutes of full outage the team can still afford. This single conversion does more for freeze negotiations than any availability chart: "we have 12 minutes of budget left and a risky payment change pending" decides the meeting.

Spend the budget by written policy

The error budget policy is agreed in calm weeks and executed in tense ones:

• Budget healthy (over 50 percent remaining). Normal deploy cadence, experiments allowed, tech-debt work scheduled opportunistically.
• Budget amber (10 to 50 percent). Feature deploys continue but each carries extra review; risky changes (payment, totals, inventory reservation) batch behind additional staging verification; on-call acknowledges the burn in the weekly review.
• Budget red (under 10 percent). Freeze on non-essential changes until the window recovers; only fixes that reduce burn ship, each with a rollback plan rehearsed, not just written.

Burn rate alerting makes the policy automatic. Alert on fast burn (budget consumed at a rate that exhausts it in hours) paging on-call immediately, and on slow burn (exhaustion in days) notifying the channel for triage. Magento-specific fast-burn triggers worth wiring: checkout 5xx ratio over 1 percent for 5 minutes, payment callback failures spiking, or queue backlog for order export growing monotonically for 15 minutes.

Pitfalls

• Too many SLOs. Ten objectives means ten budgets nobody watches. Start with two: checkout success and storefront latency. Add order freshness third only when the first two are routinely green.
• SLOs without a window. "99.9 percent" over what period decides everything. Rolling 30 days smooths campaign spikes fairly; a 7-day window during peak season reacts faster. State the window in the SLO or the number is meaningless.
• Averaging away the bad minutes. Monthly success rates hide a catastrophic Black Friday inside an otherwise calm November. Pair the headline SLO with a short-window burn alert so the average never conceals the incident.
• Budget with no consequence. If the freeze policy is overridden every time by escalation, the SLO is decoration. The first red-budget freeze must hold, visibly, or the team learns the budget is negotiable and stops watching it.
• Measuring only the happy path. Synthetic monitors that log in with cached sessions and buy a $1 SKU miss the guest-checkout, discount-stacking, multi-address paths where real failures cluster. Weight SLIs toward real-user outcomes from logs, with synthetics as the canary, not the verdict.

Closing

SLOs turn reliability from a vibe into a ledger: two or three shopper-visible objectives, a revenue-priced error budget, and a spend policy the whole business signs before peak season. With the ledger in place, the next problem is seeing the failure clearly when the budget starts burning, which is what structured logging is for.

Next in this series:

magento2-structured-logging-peak