99.99% uptime: how much downtime is that?
99.99% uptime, or four nines, allows 8.6 seconds of downtime a day, 4 minutes 23 seconds in an average month and 52 minutes 34 seconds a year. That is less time than a person needs to be paged and log in.
Downtime allowed by 99.99% uptime four nines
| Period | Allowed downtime |
|---|---|
| Daily | 8.6s |
| Weekly | 1m |
| Monthly | 4m 23s |
| Quarterly | 13m 8s |
| Yearly | 52m 34s |
| 30-day month | 4m 19s |
| 31-day month | 4m 28s |
| 28-day month | 4m 2s |
A month is the average month, a twelfth of a 365-day year; a quarter is a quarter of it.
What that looks like
Recovery has to happen without anyone: by the time a person acknowledges an alert, the month's budget is usually spent.
A bad deploy that takes five minutes to roll back misses the month on its own. So does a database failover that takes longer than expected.
How many outages fit
| One outage of | Per month | Per year |
|---|---|---|
| 1m | 4 | 52 |
| 5m | 0 | 10 |
| 15m | 0 | 3 |
| 30m | 0 | 1 |
| 1h | 0 | 0 |
| 4h | 0 | 0 |
Counts whole outages of that length that fit in the budget of an average month or a year, with nothing else going wrong.
What 99.99% takes
- Redundancy in more than one zone or region, with traffic moved away from a failing one automatically.
- Canary or progressive deploys that roll back on their own when error rates rise.
- Dependencies that are themselves at 99.99% or redundant: DNS, the database, the payment or identity provider.
- Maintenance that never takes anything offline.
Where it fits: Core infrastructure, identity and payment services, and anything other systems stop working without.
How to measure it
A tenth of the monthly budget is 26.3s, shorter than the shortest interval OpenUptime checks at (30 seconds), so checks alone cannot measure a monthly 99.99% precisely. Over a quarter a tenth of the budget is 1m 19s: check at least that often, which in OpenUptime is Lite or Starter (every minute) or Team, and judge the target over that period.
Check from more than one region, so a single network problem between one location and your server is not counted as downtime.
Compared with other targets
| Uptime | Monthly | Yearly | Downtime against 99.99% |
|---|---|---|---|
| 99% | 7h 18m | 3d 15h 36m | 100× as much |
| 99.5% | 3h 39m | 1d 19h 48m | 50× as much |
| 99.9% | 43m 48s | 8h 45m 36s | 10× as much |
| 99.95% | 21m 54s | 4h 22m 48s | 5× as much |
| 99.99% | 4m 23s | 52m 34s | this page |
| 99.999% | 26.3s | 5m 15s | 1/10 as much |
Track 99.99% uptime
OpenUptime records every check, shows uptime per monitor and on 90-day status page bars, and alerts you when a check fails.
Questions
Is 99.99% uptime realistic?
For a service built for it, yes, but it changes how you build: automatic failover everywhere, careful deploys and redundant dependencies. A single-region service with manual recovery will not get there.
How do you monitor 99.99% uptime?
A tenth of the monthly budget is 26 seconds, shorter than the 30-second minimum check interval, so measure it over a quarter or a year and check every 30 seconds from several regions.
What is the difference between 99.95% and 99.99%?
Five times the downtime: about 22 minutes a month against about 4. The step from one to the other is mostly the step from people fixing problems to systems fixing them.
99.99% 可用率意味着多少停机时间？
99.99% 可用率，也就是 4 个 9，每天允许 8.6 秒停机，平均每月 4 分 23 秒，每年 52 分 34 秒。这比一个人收到告警并登录系统所需的时间还短。
99.99% 可用率允许的停机时间 4 个 9
| 周期 | 允许的停机时间 |
|---|---|
| 每天 | 8.6 秒 |
| 每周 | 1 分 |
| 每月 | 4 分 23 秒 |
| 每季度 | 13 分 8 秒 |
| 每年 | 52 分 34 秒 |
| 30 天 | 4 分 19 秒 |
| 31 天 | 4 分 28 秒 |
| 28 天 | 4 分 2 秒 |
一个月指平均月，即 365 天的十二分之一；一个季度是一年的四分之一。
实际意味着什么
恢复必须不依赖人工：等有人确认告警时，这个月的预算通常已经用完了。
一次出问题的发布如果需要五分钟回滚，单这一次就会达不到当月目标。耗时超出预期的数据库切换也一样。
预算能容纳几次故障
| 单次故障时长 | 每月 | 每年 |
|---|---|---|
| 1 分 | 4 | 52 |
| 5 分 | 0 | 10 |
| 15 分 | 0 | 3 |
| 30 分 | 0 | 1 |
| 1 小时 | 0 | 0 |
| 4 小时 | 0 | 0 |
表示在平均月或一年的预算内，能容纳多少次这样时长的完整故障（假设没有其他问题）。
做到 99.99% 需要什么
- 在多个可用区或区域做冗余，并自动把流量从故障的一边移走。
- 金丝雀发布或渐进式发布，错误率上升时自动回滚。
- 依赖本身也达到 99.99% 或有冗余：DNS、数据库、支付或身份认证服务。
- 维护时不让任何部分下线。
适用场景： 核心基础设施、身份认证和支付服务，以及其他系统离开它就无法工作的服务。
怎样测量
月度预算的十分之一只有 26.3 秒，比 OpenUptime 最短的检查间隔（30 秒）还短，所以仅靠检查无法精确测量按月计算的 99.99%。按季度计算时，预算的十分之一是 1 分 19 秒：检查间隔不要超过这个时长（在 OpenUptime 中对应 Lite 或 Starter（每分钟）或 Team），并按季度评估目标。
从多个区域检查，这样某一个地点到服务器之间的网络问题就不会被算作停机。
与其他目标对比
| 可用率 | 每月 | 每年 | 停机时间与 99.99% 相比 |
|---|---|---|---|
| 99% | 7 小时 18 分 | 3 天 15 小时 36 分 | 100 倍 |
| 99.5% | 3 小时 39 分 | 1 天 19 小时 48 分 | 50 倍 |
| 99.9% | 43 分 48 秒 | 8 小时 45 分 36 秒 | 10 倍 |
| 99.95% | 21 分 54 秒 | 4 小时 22 分 48 秒 | 5 倍 |
| 99.99% | 4 分 23 秒 | 52 分 34 秒 | 本页 |
| 99.999% | 26.3 秒 | 5 分 15 秒 | 1/10 |
常见问题
99.99% 的可用率现实吗？
对于为此专门设计的服务来说是现实的，但它会改变构建方式：处处自动故障切换、谨慎的发布流程、冗余的依赖。单区域、靠人工恢复的服务做不到。
怎样监控 99.99% 的可用率？
月度预算的十分之一只有 26 秒，比最短的 30 秒检查间隔还短，所以要按季度或按年来衡量，并从多个区域每 30 秒检查一次。
99.95% 和 99.99% 差多少？
停机时间相差五倍：每月约 22 分钟对比约 4 分钟。从前者到后者，主要是从“人来修复问题”变成“系统自己修复问题”。