--- title: How much downtime is 99.9% uptime? Calculate it with the Uptime Calculator description: Before you promise customers 99.9% uptime, turn it into minutes: 99.9% allows 43 minutes 12 seconds of downtime in a 30-day month and 8 hours 45 minutes 36 seconds a year. Here's how to calculate uptime and downtime with the free Uptime Calculator, what a target costs in lost revenue, how much each extra nine buys, and the one-line formula to check it yourself. canonical: https://watchfor.io/blog/how-to-calculate-uptime-and-downtime --- # How much downtime is 99.9% uptime? Calculate it with the Uptime Calculator 2026-10-04 · WatchFor Team · Guides · guides, uptime, sla Before you promise customers 99.9% uptime, turn it into minutes: 99.9% allows 43 minutes 12 seconds of downtime in a 30-day month and 8 hours 45 minutes 36 seconds a year. Here's how to calculate uptime and downtime with the free Uptime Calculator, what a target costs in lost revenue, how much each extra nine buys, and the one-line formula to check it yourself. To calculate allowed downtime from an uptime percentage, multiply the period by the part that isn't uptime: downtime = period × (100 − uptime%) ÷ 100. For 99.9% that's 0.1% of the time, which is 1 minute 26 seconds a day, 43 minutes 12 seconds in a 30-day month and 8 hours 45 minutes 36 seconds a year. Going the other way, uptime = (period − downtime) ÷ period × 100. The free [Uptime Calculator](/uptime-calculator) does this for a day, a week, a month and a year at once, and turns the result into a cost estimate if you enter your revenue. ## What this tool answers *What does this uptime percentage mean in actual minutes, and what would that downtime cost us?* Reach for it before you put a number on a pricing page or into a contract, when comparing hosting offers, when someone asks whether "three nines" is good enough, or when you need to tell management what the difference between 99.9% and 99.99% is worth. ## A real example ### Calculating uptime and downtime before promising 99.9% The situation: a small B2B SaaS with about $2.4 million a year in revenue is adding an availability promise to its enterprise plan. Sales wants to say 99.9%. Engineering wants to know how much room that leaves. We entered **99.9** and **$2,400,000 yearly** in the [Uptime Calculator](/uptime-calculator): ![The Uptime Calculator at 99.9% with Downtime selected and revenue 2400000 yearly: daily downtime 1m 26s, weekly 10m 5s, monthly 43m 12s, yearly 8h 45m 36s, and a downtime cost estimation of $2,400 for the Year tab](/blog/how-to-calculate-uptime-and-downtime-result.webp) The four cards are the budget the promise leaves: | Period | Allowed downtime at 99.9% | How it's calculated | | --- | --- | --- | | Day | 1m 26s | 1,440 min × 0.001 = 1.44 min | | Week | 10m 5s | 10,080 min × 0.001 = 10.08 min | | Month (30 days) | 43m 12s | 43,200 min × 0.001 = 43.2 min | | Year (365 days) | 8h 45m 36s | 8,760 h × 0.001 = 8.76 h | And the cost: **$2,400 a year**. The calculator spreads revenue evenly over the year ($2,400,000 ÷ 8,760 hours ≈ $274 an hour) and multiplies by the 8.76 hours of allowed downtime, which comes to exactly 0.1% of revenue. **The answer:** 99.9% gives the team about 43 minutes a month. One bad deploy with a slow rollback can use that up, so it's a real commitment but not an extreme one. Changing the field to 99.99% shows what the next nine would mean: **4m 19s a month and 52m 34s a year**, about $240 a year of revenue at risk instead of $2,400. Four minutes a month is less than most teams need to notice an outage, page someone and roll back, so 99.99% only makes sense with automatic failover. ## How to read the results | What you see | What it means | | --- | --- | | **Uptime percentage** | The target you're evaluating, 0 to 100, decimals allowed (99.95). | | **Display: Downtime / Uptime** | Downtime shows the time you may be down in each period; Uptime shows the time you must be up (23h 58m 34s a day at 99.9%). | | **Daily / Weekly / Monthly / Yearly** | The period's length times the percentage. Months are 30 days and years 365 days. Values keep every unit down to seconds, so nothing is hidden by rounding. | | **Revenue + interval** | Optional. Yearly, monthly, daily or hourly revenue, converted to an hourly rate. Leave it empty and the cost panel disappears. | | **Downtime cost estimation** | Hourly revenue × allowed downtime for the tab you pick: Hour, Day, Month or Year. | ## More ways to use it - **Comparing hosting or SaaS offers.** "99.5%" sounds close to "99.9%" until the calculator shows 3h 36m a month against 43m. - **Reading an outage in percent.** Last month's 2-hour outage was 120 of 43,200 minutes: (43,200 − 120) ÷ 43,200 = 99.72% uptime. - **Sizing on-call.** At 99.95% (21m 36s a month) you can't afford to wait for someone to notice in the morning; at 99% (7h 12m) you might. - **Setting an internal target above the external one.** Promise 99.9%, aim for 99.95% internally, and treat the gap as your margin. The [error budget guide](/blog/how-to-calculate-an-error-budget) turns that margin into a burn rate. ## Tips and gotchas - **Month length changes the answer.** The calculator uses 30 days. A 31-day month gives 99.9% a budget of 44m 38s, February 40m 19s. If your contract says "calendar month", calculate with the real length. - **Monthly budgets don't roll over.** A quiet January doesn't buy extra minutes in February when the SLA is measured per month. A yearly figure of 8h 45m is not the same promise as 43 minutes every month. - **Dependencies multiply.** If your app needs a database, a payment provider and a CDN, each at 99.9%, 99.95% and 99.9%, the chance all three are up at once is 0.999 × 0.9995 × 0.999 ≈ 99.75%, if their failures are independent. Your promise can't be higher than the chain beneath it without redundancy. - **The cost is a floor.** Revenue isn't spread evenly over 24 hours: an outage at peak costs more, one at 4 a.m. less. SLA credits, support load and churn come on top. - **Define "down" before you promise.** Is a slow checkout down? One region? Does planned maintenance count? Most SLAs exclude announced maintenance; write down what counts before the first incident, not during it. [SLA, SLO and SLI](/blog/sla-slo-sli) has the vocabulary. ## Check it from the command line too The formula fits in one `awk` line. Here for four common targets, per 30-day month and per 365-day year, in minutes: ```bash awk 'BEGIN{for(i=0;i<4;i++){p=(i==0?99:i==1?99.9:i==2?99.95:99.99); m=43200*(100-p)/100; y=525600*(100-p)/100; printf "%-6s %8.2f min/30d %9.2f min/yr\n", p, m, y}}' ``` ```text 99 432.00 min/30d 5256.00 min/yr 99.9 43.20 min/30d 525.60 min/yr 99.95 21.60 min/30d 262.80 min/yr 99.99 4.32 min/30d 52.56 min/yr ``` 43.2 minutes is 43m 12s, 525.6 minutes is 8h 45m 36s, the same as the calculator. With `bc`: `echo "43200 * (1 - 0.999)" | bc -l` prints `43.200`. For the reasoning behind each nine in more depth, [what 99.9% uptime really means](/blog/what-is-99-9-percent-uptime) walks through it. ## Keep watching it The calculator tells you what a promise allows; only measurement tells you whether you kept it. WatchFor monitors check your service from several locations, count downtime only from confirmed critical incidents, leave scheduled maintenance out, and break uptime down by day, week or month on each monitor's **Uptime SLA** tab, printable as a report. A [status page](/status-pages) puts the same numbers in front of customers: each component shows its current state and a 30-day uptime heatmap with percentages, updated from your monitors. [Honest SLA reports](/blog/honest-sla-reports) covers what to show and what not to bend. ## FAQ **How much downtime is 99.9% uptime?** 1 minute 26 seconds a day, 10 minutes 5 seconds a week, 43 minutes 12 seconds in a 30-day month (44m 38s in a 31-day month) and 8 hours 45 minutes 36 seconds a year. **How do you calculate uptime percentage?** Uptime % = (total time − downtime) ÷ total time × 100. Two hours down in a 30-day month: (43,200 − 120) ÷ 43,200 × 100 = 99.72%. **What is the difference between 99.9% and 99.99% uptime?** Each extra nine divides allowed downtime by ten: 43m 12s a month at 99.9%, 4m 19s at 99.99%. The second usually requires redundancy and automatic failover, because a human response alone takes longer than that. --- Canonical page: https://watchfor.io/blog/how-to-calculate-uptime-and-downtime · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt