Downtime calculator:
how bad were those 43 minutes?
Type what happened — we grade it against the nines, price it in your own numbers, and show where the minutes actually went. The other direction from our uptime calculator, which starts at the SLA.
A month of downtime, graded
Same math as the SLA ladder, read backwards: start from the minutes you lost and see which targets survived them.
Downtime in one month → uptime grade
month = 30.42 days · 43,800 min| Downtime / month | Feels like | Uptime | Grade | Strictest target met |
|---|---|---|---|---|
| 1 minute | one bad deploy, caught fast | 99.9977% | four nines | 99.99% |
| 4m 22s | the entire four-nines budget | 99.99% | four nines | 99.99% |
| 43m 48s | the entire three-nines budget | 99.9% | three nines | 99.9% |
| 3h 39m | one bad afternoon | 99.5% | two nines | 99.5% |
| 7h 18m | a recurring problem | 99% | two nines | 99% |
| 24 hours | an incident with a name | 96.7123% | one nine | none of them |
Turning incidents into a downtime number
Three rules decide the number:
- Sum, don’t average. Downtime for the window is the sum of every incident’s duration — three short outages are not “mostly up”.
- Measure edge to edge. An incident starts at the first failed request, not the first alert — and ends when service is verified, not when the fix ships.
- Decide what “down” means — in writing. Full outage, checkout broken, or just slow? Pick the definition before the incident, or the argument happens after it.
Then it’s one division: downtime ÷ window. The ledger on the right is June for a small shop — the calculator above is that last row, graded.
One month, fully logged
caldmont.com · JuneCommon downtime questions
Two directions share one formula. Start from an SLA percentage and you get the downtime it allows (that’s our uptime calculator). Start from the downtime you actually had, as this page does, and you get the uptime percentage it produced: (window − downtime) ÷ window × 100. We add the two numbers a spreadsheet won’t give you: what it cost, and where the minutes went.
Divide downtime by the window, times 100. A 43m 48s outage in a 30.42-day month: 2,628 s ÷ 2,628,000 s × 100 = 0.1% downtime — that is, 99.9% uptime. Two rules: sum every incident in the window (don’t average them away), and measure from first failed request to verified recovery.
Two to three nines is the normal band for small-to-mid production services — 43 minutes to 7 hours per month. Three nines (43m 48s/month) is the workhorse target: reachable with good hosting, fast rollbacks and someone on call. If your month runs past 7 hours, the damage table above shows the grade you’re actually delivering — and the timeline section of the result shows where to claw minutes back first.
Skip the headline per-minute figures from enterprise surveys — they average banks into bakeries. Your ceiling is your own arithmetic: revenue per hour × hours down, plus the people who dropped everything, plus anything contractual. The cost section of the result runs it live with your numbers. Two caveats. Some interrupted buyers return later, so lost revenue is a ceiling. And some costs never fit the spreadsheet at all: trust, SEO, the support backlog.
They count however you decided they count — before the incident. Common practice: a broken critical path (checkout, login) counts in full even if the homepage renders; degraded-but-working counts separately or not at all. Write the definition down and apply it the same way every time. SLA arguments are about this paragraph, not about the arithmetic.
MTTR is mean time to recovery: total downtime ÷ number of incidents. It is your best lever, because halving it halves your downtime without preventing a single incident. MTBF is mean time between failures, or how often things break. It lives in architecture and change discipline, not response speed. Together they give availability: MTBF ÷ (MTBF + MTTR). RTO is the MTTR you promised — how long an outage may last before the recovery plan has failed. Test it before an incident does.
Attack MTTR before MTBF — recovering faster is cheaper than failing less. And within MTTR, attack detection first: it’s the only phase a tool can shrink for you outright. In our worked example, detection took 11 minutes and the fix took 4. Thirty-second checks cap the silence before the first failed check at half a minute — they can’t shorten alert delivery or the time someone takes to pick up the phone, which is why detection shrinks by four minutes here, not eleven. Diagnosis shrinks with evidence (multi-location results, exact timestamps); the fix itself shrinks with rehearsed rollbacks — that part’s on you.
You can’t calculate what you didn’t notice — the 3 a.m. reboot in our June ledger only exists because something was watching. Independent monitoring gives you the inputs this calculator needs: exact start and end times, from outside your own infrastructure. That covers every incident, including the ones nobody was awake for. Uptimia checks from 171+ locations in 70+ countries — every 60 seconds on the Basic plan, every 30 from Professional up — and keeps that ledger for you.
Keep exploring
43m 48s down = 99.9%.
Over one month, 43m 48s of downtime leaves 99.9% uptime — three nines. Below: the same minutes against four common SLA targets, what they cost in your numbers, and where they went.
43m 48s, judged against four common targets
Budgets are per window and sum across incidents — this verdict assumes these were your only minutes lost.
Verdict against four common targets
same downtime, four contractsThe formula, with your numbers
downtime percentageConvention: 365-day year, month = year ÷ 12 (30.42 days) — same as our uptime calculator and the nines ladder.
Your 43m 48s ≈ €14,037 — priced with your numbers, not a survey
Three inputs decide the bill. Edit them here — the total, the rows and the nav above update as you type.
The itemized bill
43m 48s = 0.73 hOne 43m 48s outage, and the €4.90 credit
SLA credits price the provider’s risk, not your loss. The useful question isn’t “what does the SLA pay?” but “how fast do we find out?”
11m 0s of your outage was likely pure detection lag
The typical incident splits 25% detection · 39% diagnosis · 9% fix · 27% recovery. Applied to your 43m 48s — detection is the slice a tool deletes outright.
Your 43m 48s, cut by phase
typical split, drawn to scaleAt your bill above, the detection slice alone ≈ €3,525. Monitoring can’t fix your deploy — it deletes this slice.
How one 43m 48s outage actually played out
With 30-second checks the 11:08:40 line becomes 11:04:30: the silence before the first failed check drops from 4m 40s to 30 seconds, and every line below it moves up by those four minutes.
Free tools are just the start.
Uptimia keeps your sites healthy.
Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.