Uptime promises are written as percentages because they look impressive. 99.9% sounds close to perfect. It is easier to judge a promise once it is turned into time: how long the service can be down before the promise is broken.
The calculation
Subtract the uptime from 100% to get the share of time the service is allowed to be down, then multiply by the length of the period. Using a 365-day year:
Allowed downtime share
100% − 99.9%equals0.1%
Per year
0.1% × 365 d × 24 hequals8h 45m 36s
Per month
8h 45m 36s ÷ 12equals43m 48s
The nines at a glance
- 99% (two nines): 3d 15h 36m a year, about 7h 18m a month.
- 99.9% (three nines): 8h 45m 36s a year, 43m 48s a month.
- 99.95%: 4h 22m 48s a year, 21m 54s a month.
- 99.99% (four nines): 52m 34s a year, 4m 23s a month.
- 99.999% (five nines): 5m 15s a year, about 26 seconds a month.
Going from three nines to four nines is not a small improvement. It means being down for under an hour a year instead of most of a working day, and it usually takes redundant infrastructure and on-call processes to achieve.
Your uptime depends on your dependencies
If your app needs a database and a payment provider, and both promise 99.9%, you cannot promise 99.9% yourself. If either one going down takes you down, the combined figure is roughly 0.999 × 0.999, or about 99.8%. Every hard dependency lowers the ceiling.
Read the fine print
- Planned maintenance is often excluded from the calculation.
- Some agreements measure per calendar month, which changes the exact minutes.
- "Down" may only count full outages, not slow responses or partial failures.
- The remedy for a missed target is usually a service credit, not a refund of your losses.
Tip: Set your internal target a little tighter than the uptime you promise customers. It gives you room to respond before a breach.