99.9% uptime means 8 hours 46 minutes down. Per year.

99.9% sounds like "basically always up". Do the maths and it's 8 hours 46 minutes of downtime a year.

The maths

A year has 8,760 hours. Three nines lets you be down 0.1% of that.

Each extra nine cuts your allowance by ten. Going from three to four nines means going from a bad afternoon to under an hour, for the whole year.

One night can spend the whole year

On October 19–20, 2025, a DNS race condition left Amazon DynamoDB's regional endpoint in AWS us-east-1 with an empty DNS record. Per AWS's own post-event summary, the disruption ran from 11:48 PM to 2:20 PM PDT: about fourteen and a half hours.

If you depended on that path and had promised 99.9%, that single event used more than your full year's budget. You don't get those hours back by being extra careful in December.

Uptime is a budget, not a promise

This is the idea behind error budgets in Google's SRE book: a target below 100% is permission to spend some unreliability on change. When the budget is healthy, ship. When it's spent, slow down and fix reliability.

• Pick the target from user impact, not from what sounds impressive in a contract.
• Know your dependencies' targets. You can't be more available than the things you hard-depend on, unless you design around them.
• Spend the budget on purpose: deploys, migrations and chaos experiments, rather than letting surprises spend it for you.

The budget will get spent either way. The only choice is whether you're the one spending it.

Sources

• Google SRE book: Embracing Risk
• AWS post-event summary: us-east-1, October 2025