SLA 99.9% vs 99.99%: when paying for extra nines is a waste

On the hosting deck: 99.99% uptime. In the client contract: a penalty for every hour down. Inside the company: “we’ll reboot if needed.” Three different promises — only one is tied to real money.

Bottom line. Each “nine” in SLA is a budget line: redundancy, monitoring, on-call, testing. For most services, honest 99.9% on the critical path is enough — if you measure it instead of copying the vendor slide.

The nines table: how much downtime that is

Answer: the gap between 99.9% and 99.99% is not “0.09% more” — it is an order of magnitude in unavailable time.

• 99.9% — ~8h 45m/year, ~43m/month
• 99.95% — ~4h 23m/year, ~22m/month
• 99.99% — ~52m/year, ~4m/month
• 99.999% — ~5m/year

For executives: 99.9% ≈ one business day down per year; 99.99% ≈ one hour. Moving up a level costs multiples, not increments — see SRE for business.

SLA, SLO, and “uptime in the hosting panel”

Answer: do not mix three things.

• SLI — what we measure (success rate, p95, “payment completed”).
• SLO — team target (99.9% successful checkouts per month).
• SLA — customer promise + consequences (credit, penalty, termination).

Provider “99.9% uptime” often pings the homepage, not your money path. Hosting can be green while cart and checkout are failing.

When 99.9% is a fair target

Answer: when an hour down hurts but does not destroy the business and there is no strict B2B penalty.

• Marketing site without checkout on the same domain
• Internal portal, HR forms, non-critical “by Monday morning” reports
• B2B portal where partners tolerate a short blip without liquidated damages
• Staging and integration sandboxes

Reasonable setup: monitoring on 3–4 signals, 3-2-1 backups, a runbook for who restores what — without 24/7 on-call.

When paying for 99.99% makes sense

Answer: when the cost of a minute down exceeds the cost of the extra nine.

• Checkout, acquiring, order API during peaks (promo, reporting period)
• Enterprise contract with SLA + penalties
• Tender where “99.99%” is a formal filter (you need proof, not a slide)
• Single entry point for a dealer/franchise network with no offline workaround

Hourly downtime math — in our downtime cost guide. If one hour = 100–200k RUB, one ruined promo pays for a year of “saved” monitoring.

What each nine buys (simplified)

99.9%	Single DC or cloud, business-hours alerts, manual deploy with rollback, backups with rare restore tests
99.95–99.99%	DB replica, health checks, failover or fast runbook, on-call, load test before peak
99.999%	Multi-AZ/region, chaos practices, SRE process, error budget — overkill for most SMBs at start

Peak readiness is separate: even at 99.9% “on average” you can fail on promo day. See preparing for high load and the peak season checklist.

Five questions for the executive

1. What does an hour of downtime cost in RUB?
2. Is there a contract penalty for SLA? If yes, IT must own measurable SLIs.
3. Which path is critical? One number for “the whole site” is wrong — split checkout, API, portal.
4. Who is on call and how fast do they recover? Without an answer, 99.99% on paper ≈ 99.5% in reality.
5. When did you last test restore/failover? Backups and failover “in theory” do not count.

Summary

99.9% vs 99.99% is not “worse / better” — it is a different cost class. For most B2B portals and storefronts outside peak, honest 99.9% on the critical path plus peak prep is enough. 99.99% pays off when downtime is priced in money and fixed in the contract.

To align SLO with your contract or check if the system survives a promo — start with a performance audit or load testing: in 1–2 weeks we fix targets, metrics, and priorities without buying nines you do not need.