99.99 uptime calculator
At 99.99% uptime the calculator gives 8.64s of allowed downtime per day, 1m 0.48s per week, 4m 22.98s per month, 13m 8.94s per quarter and 52m 35.76s per year.
99.99% uptime allows 52m 35.76s of downtime a year.
| Period | Downtime allowed |
|---|---|
| Day | 8.64s |
| Week | 1m 0.48s |
| Month | 4m 22.98s |
| Quarter | 13m 8.94s |
| Year | 52m 35.76s |
Four nines is where the maths stops being abstract. The calculator assumes 24/7 service, a 365.25-day year and a 30.44-day month, and at 99.99% one ten-thousandth of each period is all you get. That is less time than most deploys take.
99.99 uptime: the full table
- Per day: 8.64 seconds
- Per week: 1m 0.48s (60.48 seconds)
- Per month: 4m 22.98s (262.98 seconds)
- Per quarter: 13m 8.94s (788.94 seconds)
- Per year: 52m 35.76s (3,155.76 seconds)
The same numbers in awk
# Allowed downtime at 99.99% uptime, in seconds. Change p for any target.
awk -v p=99.99 'BEGIN {
year = 365.25 * 86400
printf "day %9.2f s\n", 86400 * (1 - p / 100)
printf "week %9.2f s\n", 604800 * (1 - p / 100)
printf "month %9.2f s\n", year / 12 * (1 - p / 100)
printf "quarter %9.2f s\n", year / 4 * (1 - p / 100)
printf "year %9.2f s\n", year * (1 - p / 100)
}'
# day 8.64 s
# week 60.48 s
# month 262.98 s
# quarter 788.94 s
# year 3155.76 s99.99 uptime per month
4m 23s a month means one restart that takes 5 minutes is already a missed month. Calendar months shift it by seconds, not minutes: 4m 1.92s in February, 4m 19.2s in a 30-day month, 4m 27.84s in a 31-day month. A single instance cannot hit this. Every deploy, every host reboot and every config change that bounces the process spends the budget. Four nines on one box is a claim, not an architecture.
99.99 uptime per year
52m 35.76s a year sounds like one long lunch break, which is why yearly four nines gets promised so often. One hour-long outage, the usual cost of a bad migration, breaks the whole year on its own at 99.989%. If you promise 99.99 per year, you are promising that the worst incident of the next twelve months stays under 53 minutes, and that nothing else goes wrong at all.
Four nines availability needs a faster monitor
A monitor cannot report what it does not sample. Logdash counts successful checks over all checks, a success being a 200 to 399 status within 10 seconds. At a 5-minute interval the monthly budget is 0.88 of one check, so a single failure, 0.0114% of the month, takes you to 99.9886%. At 1 minute you may fail 4 checks a month. At 15 seconds, the Pro interval, you may fail 17. Only the 15-second interval is fine enough to tell a 30-second blip from a 4-minute outage.
- Monitor what users hit Create a service in Logdash and point the monitor at your public URL or at a health route that runs one database query. Each check stores the status code and the response time.
- Use the 15-second interval Pro checks every 15 seconds, 175,320 checks a month. Builder checks every minute and the free plan every 5 minutes, which is fine for 99.9 and too coarse for 99.99.
- Hear about it in seconds, not minutes Connect Telegram and kill the process. Within one 15-second interval the check fails, the monitor flips to down and the Telegram alert arrives with the monitor name and the status code, while most of the 4m 23s is still unspent.
Measuring 99.99: Logdash vs Better Stack
| Feature | Logdash | Better Stack |
|---|---|---|
| Fastest check interval | 15 seconds on Pro, $15 a month | 30 seconds on paid plans |
| Failed checks that fit in 4m 23s | 17 at 15 seconds | 8 at 30 seconds |
| Check locations | One location | Multi-location and geo-specific checks |
| SLA reporting | Uptime badges for 24h, 7d, 30d and 90d | Uptime SLA reports built in |
| Alert channels | Telegram and webhook | Email, Slack, SMS and phone calls |
When Better Stack is the better pick
- You sell four nines with a contract behind it. Multi-location checks stop one bad network path from costing you a credit, and Logdash checks from one place.
- You need a phone call at 3am. A 4-minute budget does not survive a Telegram message on a muted phone.
- You want SLA reports to send to a customer, not a badge on a README.