Availability, SLOs and error budgets
In one line
Decide how reliable a service must be from the user's point of view, measure exactly that, and treat the remaining unreliability as a budget you can spend on releases and risk.
What it is
Availability is the share of time, or of requests, in which a system does its job. It is usually written in 'nines': 99.9% ('three nines') allows about 43 minutes of failure in a 30-day month, 99.99% allows about 4.3 minutes. Each extra nine costs much more in engineering and infrastructure.
Three terms are often mixed up. An SLI (service level indicator) is a measurement, for example 'the share of checkout requests that return success within 1 second'. An SLO (service level objective) is the internal target for that SLI, for example '99.9% over 30 days'. An SLA (service level agreement) is a contract with customers, with refunds or credits when it is missed; it is usually looser than the SLO so you have a safety margin.
The error budget is 1 minus the SLO. With a 99.9% SLO over 30 days and 100 million requests, you may fail 100,000 of them. While budget remains, teams ship quickly and take risks. When it is spent, the agreed policy kicks in: freeze risky launches, focus on reliability work, or slow deployments. The budget turns 'how reliable should we be?' from an argument into a number.
Why interviewers ask
Almost every design prompt has a non-functional requirement like 'highly available'. Interviewers want you to turn it into a number, explain what that number means in minutes of downtime, show how availability of serial dependencies multiplies down, and know when redundancy is worth the cost. Senior candidates are expected to define SLIs from the user's view, talk about burn-rate alerts, and explain why 100% is the wrong target.
How it works
- 1Pick the critical user journeys: for a payments app, 'pay a merchant', 'check balance', 'see transaction history'. Each journey gets its own SLOs, because they do not need the same reliability.
- 2Define SLIs as good events divided by valid events, measured as close to the user as possible (load balancer logs or client telemetry, not CPU graphs). Common types: availability (non-5xx responses), latency (share of requests under a threshold, for example 95% under 300 ms), freshness (data younger than N minutes), correctness and durability.
- 3Set the SLO from user needs and from what the dependencies can support, not from wishes. Start slightly below current performance and tighten later.
- 4Know the downtime table for 30 days: 99% = 7.2 hours, 99.5% = 3.6 hours, 99.9% = 43.2 minutes, 99.95% = 21.6 minutes, 99.99% = 4.32 minutes, 99.999% = 26 seconds.
- 5Compute composite availability. Serial dependencies multiply: a service that needs three dependencies, each 99.9%, can be at most about 99.7%. Redundant parallel copies improve it: two independent 99% replicas give 1 - 0.01 x 0.01 = 99.99%, but only if their failures are truly independent.
- 6Write an error budget policy with product and engineering leads: what happens at 50% burn, at 100% burn, and who can make exceptions.
- 7Alert on burn rate, not on single errors. Burn rate 1 means you would use exactly the whole budget over the SLO window. The Google SRE workbook suggests paging when a 1-hour window burns at 14.4x (2% of a 30-day budget in an hour) and opening a ticket for slower burns over 6 hours or 3 days; a short confirmation window (for example 5 minutes) stops alerts that already recovered.
- 8Review SLOs regularly: if you always meet them with huge margin, you may be over-investing; if users complain while SLOs are green, your SLIs measure the wrong thing.
Worked example · SLO for a UPI-style 'pay merchant' API
- Traffic: 50 million payment requests a day, about 1.5 billion in 30 days.
- SLI: share of valid payment requests that get a final success or a clear business decline (insufficient funds counts as good) within 5 seconds, measured at the load balancer. Timeouts and 5xx count as bad.
- SLO: 99.95% over a rolling 30 days. Error budget = 0.05% x 1.5 billion = 750,000 bad requests, or about 21.6 minutes of full outage.
- Dependencies in series: API gateway 99.99%, payment service 99.99%, Postgres primary with failover 99.99%, bank switch 99.95%. Product = 0.9999^3 x 0.9995 is about 99.92%, which is below the 99.95% target.
- Conclusion: either the target is unrealistic, or the design must remove the weakest serial link, for example by routing to a second bank partner when the first is failing, or by accepting the payment and confirming asynchronously.
- Burn alert: at 50 million requests a day, a normal hour has about 2 million requests and the budget allows about 1,040 bad requests per hour (750,000 / 720 hours). A 14.4x burn is about 15,000 bad requests in an hour, or 0.72% errors: page the on-call.
- Mid-month, a bad deploy fails 3% of payments for 10 minutes: about 350,000 x 0.03 = about 10,400 bad requests, roughly 1.4% of the budget. Painful but affordable; a full 2-hour outage (about 4 million failed requests) would spend more than the whole month's budget and trigger the release freeze.
Picture it
An error budget is like a monthly mobile data plan. You do not try to use zero data; that would waste what you paid for. You spend it on what you value (new features, fast releases). When you get close to the limit you slow down, and when it runs out you stop streaming until the next cycle. Watching how fast it drains (burn rate) is more useful than looking at a single download.
Key patterns
Multi-window, multi-burn-rate alerts
When: Alerting on any SLO
How: Page when both a long window (1 h) and a short window (5 min) burn fast (for example 14.4x); ticket for slow burns over 6 h or 3 days. Catches big outages fast and slow leaks without noise.
Graceful degradation to protect the critical SLO
When: A non-critical dependency threatens a critical journey
How: Make recommendations, reviews or AI summaries optional with their own looser SLO, so their failure does not count against checkout.
Remove serial dependencies
When: Composite availability is below target
How: Cache, make calls asynchronous, add a second provider, or move the dependency off the critical path, since each serial dependency multiplies availability down.
Real-world use
Google SRE
Google's SRE books introduced SLOs, error budgets and multi-window burn-rate alerts. A famous example is Chubby, Google's lock service: when it was more reliable than its SLO, the team planned controlled outages so other teams would stop depending on more availability than promised.
Cloud provider SLAs
AWS, Google Cloud and Azure publish SLAs per service, for example monthly uptime commitments for single-region compute or storage, with service credits when they miss them. Credits are small compared with your own losses, so your design cannot rely on an SLA alone.
Durability vs availability at S3
Amazon S3 Standard is designed for 99.999999999% (eleven nines) durability but a 99.99% availability design target and a lower SLA. Losing data and being temporarily unreachable are different SLIs with different targets.
Indian payment and trading systems
For UPI apps and stock brokers like Zerodha, the critical journeys are 'pay' and 'place order during market hours'. Market-hours or business-hours SLOs are common, because an outage at 9:15 am when the market opens costs far more than one at 2 am.
In a project
Your team runs the order and tracking backend of a quick-commerce app. Releases go out 20 times a week, incidents are frequent, and product and engineering argue every week about whether to freeze releases.
- Identify three critical journeys: place order, see live order status, and see store catalogue.
- Define SLIs from load balancer logs: place order succeeds in under 2 s; status data is less than 30 s old; catalogue p95 under 400 ms.
- Set initial SLOs just under the last quarter's real numbers: 99.9% for place order, 99.5% for status freshness, 99% for catalogue latency.
- Agree an error budget policy: above 50% burn, every release needs a canary; above 100%, only reliability fixes and urgent business changes ship until the window recovers.
- Replace dozens of CPU and error-count alerts with burn-rate alerts (fast burn pages, slow burn creates a ticket).
- Publish a weekly SLO dashboard and review it in the planning meeting; use budget spent per cause (deploys, dependency outages, capacity) to choose reliability work.
Impact: The release debate becomes a number on a dashboard. Pages drop because alerts fire only when users are really affected, and reliability work is prioritised by how much budget each cause burns.
Trade-offs
Use it when
- Any service with users who notice failures, internal or external
- Teams that need an objective way to balance release speed against stability
- Choosing how much redundancy (multi-AZ, multi-region, second provider) is worth paying for
- Agreeing reliability expectations with dependent teams and partners
Avoid it when
- Targeting 100%: impossible, extremely expensive, and users cannot tell the difference beyond what their own network gives them
- Copying another company's numbers without checking what your users and dependencies need and allow
- Defining SLIs on internal signals (CPU, pod restarts) that do not reflect user experience
- Setting an SLO tighter than the product of your serial dependencies' availability
Common mistakes
- Saying 'five nines' without knowing it means about 5 minutes of downtime a year.
- Mixing up SLA (contract), SLO (internal target) and SLI (measurement).
- Forgetting that serial dependencies multiply: 5 dependencies at 99.9% cap you at about 99.5%.
- Assuming two replicas give 99.99% when they share a database, network or deploy pipeline and fail together.
- Using averages for latency SLOs instead of percentiles or 'share of requests under X ms'.
- Alerting on every error spike instead of burn rate, causing alert fatigue.
- Having an error budget with no agreed policy, so nothing changes when it runs out.
Interview questions
Quick revision
- SLI = measurement, SLO = internal target, SLA = contract with penalties (looser than SLO).
- Error budget = 1 - SLO over a window (usually 28 or 30 days).
- 30 days: 99.9% = 43.2 min, 99.95% = 21.6 min, 99.99% = 4.3 min, 99.999% = 26 s.
- Serial: multiply availabilities. Parallel independent: 1 - product of failure rates.
- Measure SLIs near the user: load balancer or client, not CPU.
- Latency SLO = share of requests under a threshold, not an average.
- Separate SLOs per critical journey; optional features get looser ones.
- Burn rate 1 = budget lasts exactly the window; page at ~14.4x over 1 h.
- 100% is the wrong target; each extra nine costs far more (often quoted as about 10x).
- Durability and availability are different SLIs.
Check yourself
1. About how much downtime does a 99.9% availability SLO allow in a 30-day month?
2. A request must pass through three components in series, each 99.9% available. What is the best possible end-to-end availability?
3. Which statement about SLAs and SLOs is correct?
4. What is the best SLI for 'checkout is fast'?
See it in a full design
These walkthroughs use this lesson.
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.