Uptime Calculator — Downtime in Minutes

Availability is sold in nines and experienced, during every incident review, in minutes and seconds. “99.9% uptime” sounds like perfection until it is translated: about 43 minutes of downtime a month. Enter any availability percentage, and this calculator converts it into the downtime it actually permits — per day, week, month and year — in the minutes, seconds and hours you can plan an incident budget around.

The Nines, Translated Into Minutes

Availability percentages compress brutally, and this calculator exists to decompress them. The ladder, in monthly downtime, runs: 99% allows about 7.2 hours down a month; 99.9% allows 43.2 minutes; 99.99%, 4.3 minutes; 99.999%, about 26 seconds; and each further nine divides by ten again. The translation reframes every SLA conversation: the difference between three nines and four is not 0.09% of anything — it is thirty-nine minutes a month of incident budget, the difference between “a reboot is an incident” and “a reboot is a rounding error”. It also prices ambition honestly in the other direction: five nines is 5.3 minutes of downtime a year, a budget that a single botched deploy spends entirely, which is why so few services honestly sign it and why the ones that do are engineered like aircraft.

Worked Example: The Standard Cloud SLA Figure

The default selection is the industry’s workhorse: 99.9%, the figure attached to most cloud services. The translation: per day about 1 minute 26 seconds of downtime; per week about 10 minutes; per month 43.2 minutes; per year about 8 hours 46 minutes. Read a real incident against it: a single 45-minute outage in a month has spent the month’s entire budget — the SLA is breached, credits are owed, and the post-mortem writes itself. This is the sense in which the calculator is a negotiating instrument as much as a converter: a buyer who has run the numbers knows what a vendor’s nine actually promises, and a vendor quoting 99.95% is offering to halve the incident budget of 99.9% — a concrete, priceable thing, once it is stated in minutes.

Error Budgets: The Constructive Use of Permitted Downtime

Site reliability engineering turned this translation into a management philosophy: the permitted downtime is an error budget, and it is meant to be spent. A team far inside its budget is being too cautious — shipping too slowly, gold-plating reliability nobody bought; a team that has spent it freezes feature work until reliability recovers. The budget reframes the eternal product-versus-stability argument as arithmetic: the SLA’s nines, converted by exactly this page’s multiplication, minus the incidents already burned, equals the risk the team may take this quarter. It also disciplines measurement arguments: the budget is computed from the user’s experience of availability (successful requests over total requests, in the modern formulation), not from whether a server’s heartbeat blinked — a definitional choice that moves real percentages by more than a nine, and that the calculator’s note warns belongs to the contract.

Composite Availability: The Nines Multiply Away

One warning for architects reading the ladder with intent: services chained in series multiply their availabilities, and the product is always worse than the worst link’s brochure. A request path crossing three independent 99.9% services inherits about 0.999³ ≈ 99.7% — three weeks’ worth of the single-service monthly budget, every month — before your own code’s availability enters the multiplication at all. This is why real architectures budget availability per user journey rather than per component, parallelise what can be parallel (redundant paths add their downtimes‘, not their uptimes — two 99% paths in parallel fail together only 0.01% of the time), and treat every serial dependency as a nine spent. The calculator converts single percentages; the multiplication across a diagram is the reader’s homework, and it is the difference between an SLA and a hope.

Status Pages: The Ladder Made Public

The cultural endpoint of these translations is the public status page, where providers display rolling 90-day availability against their own SLAs — a genre that has taught a generation of buyers to read nines the way this calculator translates them. Its conventions are instructive: partial degradations count fractionally or not at all by each provider’s private rubric, historical months are revised as late data arrives, and the displayed figure is a marketing surface as much as an engineering one. None of that invalidates the instrument; it returns the reader to this page’s discipline, which is to convert any quoted availability into minutes, ask whose measurement produced it, and price the answer against the work those minutes protect. The nines are a language; minutes are the meaning.

Availability Versus Durability: A Necessary Distinction

Buyers conflate two promises the ladder does not make: availability says the service answers now; durability says its data survives — the cloud’s famous “eleven nines” figures belong to storage durability, an annual probability of losing an object, not a uptime at all, and quoting them in an availability conversation is comparing a seatbelt to a clock. The calculator’s percentages belong strictly to the answering-now family. A system can be gloriously available and quietly losing data (backups unrun, replicas lagging), or durable and down for a weekend. Contracts, like calculators, serve best when each number is kept in its own column — and the reader who has translated the nines into minutes is already most of the way to asking which column a given promise lives in.

Related Tools

More from the Other Calculators hub: the Bandwidth Calculator for the pipe the uptime protects, and the DPMO Calculator — defects per million, the manufacturing dialect of the same reliability language.

Frequently Asked Questions

How much downtime is 99.9% per month, in minutes?

43.2 minutes — the worked example — computed on a 30-day month (43,200 minutes × 0.1%). Per year it is about 8 hours 46 minutes. The figure surprises nearly everyone the first time, in both directions: marketing departments hear how generous three nines are, and engineering teams hear how thin the ice is under a single bad deploy on a Friday afternoon. Both hearings are the calculator doing its job, which is why the monthly figure leads every serious SLA discussion.

What does “five nines” mean in practice, day to day?

99.999% availability: about 5.3 minutes of downtime per year, 26 seconds a month. Historically it was the telephone network’s standard, achieved with hardware redundancy and glacial change rates; in software it demands multi-region failover, automated everything, and change processes that treat a human touching production as an incident category. It is purchasable, at a price that climbs steeply per nine — the calculator’s ladder is also a price curve’s silhouette, and most services discover their honest number is three nines with fast, practised recovery rather than five with theatre and hope.

Is scheduled maintenance counted as downtime under an SLA?

Usually not — most SLAs exclude announced maintenance windows from the calculation, which is one of the contract definitions the calculator’s note insists on reading. The exclusion is reasonable (planned work at 3 a.m. harms no one) and gameable (maintenance declared liberally enough swallows real incidents), and the industry’s corrective is the user’s-eye definition: if users could not use the service, it was down, whatever the calendar called it. When comparing providers, compare their definitions before their nines; a 99.9% with user-eye measurement can be a stronger promise than 99.99% measured by the provider’s ping.

How is uptime measured — time elapsed or requests served?

Two dialects: time-based (the fraction of minutes the service was up, this page’s framing) and request-based (successful requests ÷ total requests, the SRE framing). They diverge exactly where it matters: a service down for 3 minutes at peak hour fails far more requests than one down for 30 at 4 a.m., and request-based measurement knows it while time-based does not. Contracts specify one; status pages often display the flattering one. The calculator converts percentages under the time convention — the SLA standard — while the error-budget section names the alternative so the reader can interrogate which dialect a given nine is speaking.

What uptime should my small website target, honestly?

Honestly stated: 99.9% (three nines) is a strong, achievable target for a competently hosted small site — good hosting, monitoring, and tested backups — and it still permits a bad evening a month. Chasing the fourth nine costs more than most small sites’ entire budget and buys minutes their audiences will never notice. The calculator’s real gift to the small operator is the monthly figure in advance: knowing you have 43 minutes of incident budget tells you how much monitoring, redundancy and rehearsal are proportionate — reliability, like insurance, is bought correctly only against a priced risk.

Can uptime exceed what this table shows — is 100% possible, ever?

Over a short enough window, trivially; over years, no — every system meets its incident eventually, and a provider claiming a sustained 100% is reporting its measurement’s blind spots. The mature reading of the ladder is that availability is a budget to manage, not a state to achieve, and the last decimal places in the selector (six nines: about 32 seconds a year) exist to show where the mathematics of the promise outruns any plausible engineering — a useful boundary to be able to point at in a sales meeting.