Uptime percentage is (total time minus downtime) divided by total time, multiplied by 100. Flip that around and it tells you a downtime budget: how many minutes a month you're allowed before you miss the number. 99.9% buys you about 43 minutes a month. 99.99% buys you about 4 minutes 19 seconds. Every uptime calculator online will give you a version of that table. Almost none of them mention that the table is only useful if your monitor checks often enough to notice an outage before it eats the whole budget, or that two calculators can show different numbers for the same 99.9% depending on which month they're quietly assuming.
How do you calculate uptime percentage?
The formula: uptime % = (total time − downtime) ÷ total time × 100.
Say a service was down for 26 seconds over a 24-hour day. That's:
(86400 − 26) ÷ 86400 × 100 = 99.97%
Run the same formula backward and you get a downtime budget instead of a percentage: pick the uptime target first, and the formula tells you exactly how many seconds of downtime that target allows over a given period.
allowed downtime = period in seconds × (100 − uptime %) ÷ 100
That's the whole calculator. Everything past this point is just running that formula at different percentages and periods, and being honest about what the resulting number can and can't tell you.
How much downtime does each uptime percentage actually allow?
Here's the budget at the tiers people actually quote, using a flat 30-day month and a 365-day year:
Uptime Per day Per week Per month (30d) Per year (365d)
99% 14m 24s 1h 40m 48s 7h 12m 0s 3d 15h 36m
99.5% 7m 12s 50m 24s 3h 36m 0s 1d 19h 48m
99.9% 1m 26s 10m 5s 43m 12s 8h 45m 36s
99.95% 43s 5m 2s 21m 36s 4h 22m 48s
99.99% 8.6s 1m 0s 4m 19s 52m 34s
99.999% 0.9s 6.0s 25.9s 5m 15s
Each nine you add cuts the allowed downtime by roughly a factor of ten. Going from 99% to 99.9% is the difference between "a bad afternoon" and "a bad coffee break." Going from 99.9% to 99.99% is the difference between a coffee break and a bathroom break.
Why do different uptime calculators show different numbers for 99.9%?
Open three uptime calculators and ask for 99.9% uptime over a month, and you'll get at least two different answers, both "correct." The gap is the month itself. A flat 30-day month gives 43 minutes 12 seconds. A 30.44-day average month (365.25 days ÷ 12, the convention some calculators use so the number doesn't change every month) gives roughly 43 minutes 50 seconds. Neither is wrong; they're answering slightly different questions, and most calculator pages don't say which one they picked.
It matters less than it looks like it does. The spread between those two numbers is under a minute, dwarfed by the next section's problem.
Can you even measure 99.99% uptime on a 5-minute check interval?
No, and this is the part no calculator table tells you. A monitor that polls every 5 minutes can only confirm something is down up to 5 minutes after it actually went down, in the worst case where the outage starts right after a check just passed. That worst-case detection delay is baked into the check interval; nothing about the monitor's dashboard changes that.
Compare that delay to the budgets above:
- At 99.9% (43m 12s/month budget), a 5-minute worst-case detection delay eats about 12% of the entire month's budget before you've done anything else: not responded, not fixed it, just noticed.
- At 99.95% (21m 36s/month), that same 5-minute delay eats about 23% of the budget.
- At 99.99% (4m 19s/month), the 5-minute delay is longer than the entire monthly budget. A 5-minute check interval cannot measure or defend 99.99% uptime, structurally, no matter how reliable the service actually is.
Drop the check interval to 60 seconds and the same worst-case delay shrinks to 1 minute: about 2% of the 99.9% budget, 5% of the 99.95% budget, and 23% of the 99.99% budget instead of blowing past it entirely. The tighter the target, the more the check interval itself becomes the binding constraint, not your actual infrastructure. (CanaryHub's free tier checks every 5 minutes; its paid tier checks every 60 seconds, for exactly this reason.)
What uptime percentage should a solo developer actually promise?
Promise the number your setup can actually hold, not the one that sounds impressive in a pricing page. 99.99% and tighter assumes fast detection and fast response, which usually means an on-call rotation, not a single person who also needs to sleep. For most solo developers and small teams, 99.9% is the honest working target: a 43-minute monthly budget is large enough to absorb one bad deploy caught the same day, without requiring you to be awake and online the instant something breaks.
Treat the budget as something to spend deliberately, not something to be surprised by. A rough split that works for a lot of solo projects: reserve a few minutes for planned deploys and migrations, and leave the rest for the unplanned stuff. If you're routinely blowing through 43 minutes a month in unplanned downtime, the fix is almost always faster detection (a shorter check interval) and faster notification (an alert that reaches you directly, not an inbox you check twice a day), not a fancier infrastructure budget.
What about jobs that don't get an uptime percentage, like a cron job?
Everything above assumes something you poll over HTTP, where "up" and "down" are states a monitor can check. A background job (a nightly report, a cleanup script, anything running on a schedule rather than answering requests) doesn't have an uptime percentage at all. It either ran on schedule or it didn't; there's no partial-credit version of "my cron job was 99.9% available this month."
The equivalent tool for that case is a heartbeat, or dead man's switch: instead of polling something and expecting a response, the job itself pings the monitor after it finishes. CanaryHub's heartbeat monitors treat silence past the job's expected interval plus a grace period as down on the very first missed check, with no second-failure buffer, because the grace period is already the buffer. It's the same underlying question as an uptime calculator (how much absence can you tolerate before it's a problem), just asked about a schedule instead of a percentage. More on setting one up in how to monitor a cron job.
The number only means what your monitoring lets it mean
The formula is five seconds of arithmetic. The budget table is a lookup. The part worth sitting with is that a downtime budget is a promise about detection and response just as much as it's a promise about infrastructure, and a monitor checking every 5 minutes cannot honestly back a target smaller than a few minutes a month, no matter how good the uptime actually is. Pick the tier your check interval and your actual response time can support, not the one with the most nines.