A 99.9% uptime target allows 8 hours, 45 minutes and 58 seconds of downtime a year. In an average month, that is 43 minutes and 50 seconds. The uptime calculator returns this budget for any service-level agreement (SLA) percentage, from a day to a year. Engineers and buyers can see what a contract allows before they sign.

Common SLA levels

Uptime	Per day	Per month	Per year

How this is calculated

How it works: Availability is uptime divided by total time, the measure in the AWS Well-Architected reliability pillar (opens in new window). The average month is 365.25 ÷ 12 days (30.44) and a year is 365.25 days; the 28-, 30- and 31-day rows are calendar months, which is what most monthly SLAs measure. With set hours, only those hours count toward the period. Services that all must be up multiply their uptimes; redundant copies fail only when every copy is down at once, so their downtime shares multiply instead.
Not covered: No maintenance-window exclusions or SLA credits; set hours are averaged over the period, not mapped to real weekdays.
Privacy: What you enter never reaches our server. It is processed on your device, inside this page.
Corrections: Report a wrong result to media@sqmagazine.co.uk; every report is reviewed and confirmed errors are corrected. Include the inputs and the answer you expected. With your permission, we thank you by name on this page.
Updates: Oct 5, 2026 Published.
Feedback: How useful was this tool?

Table of Contents

How to Use the Uptime Calculator

The uptime calculator needs one input: the “Agreed uptime” percentage from your SLA. It returns the downtime that percentage allows per year, quarter, month, week and day. It runs in your browser, so nothing you type is sent to a server.

Type the availability your SLA promises into “Agreed uptime”, for example 99.9 for three nines. The field takes values from 0 to 100 in steps of 0.001.
Start with “Downtime allowed per year”, then read “Per quarter”, “Per month”, “Per week” and “Per day”.
Check “Nines”, which names a value made only of nines, such as “three nines” for 99.9, and stays blank when other digits appear.
Tap an “Examples” chip to load one of four preset levels, from three nines to five nines, or use “Share result” to copy a URL that reopens your input.

A bar chart and the “Common SLA levels” table sit below the answer. Every figure in the panel comes from one line of arithmetic.

How Allowed Downtime Is Calculated

Any downtime calculator multiplies the period’s length by the share of time that an uptime percentage leaves uncovered. For example, AWS’s Well-Architected guidance on availability defines availability as a percentage uptime (such as 99.9%) over a period of time (commonly a month or year).

With U as the uptime percentage and T as the length of the period:

Allowed downtime = T × (1 – U / 100).
Year: T is 365.25 days, or 31,557,600 seconds.
Quarter, month, week and day: a quarter of the year, a twelfth, 7 days and 1 day.

As a result, a month here averages 30.44 days, and that is where calculators and contracts part ways. By contrast, AWS measures Amazon EC2 uptime during any monthly billing cycle, and Google scores Compute Engine on a calendar month basis per Project per Region or, for a Single Instance, per instance. Microsoft’s Azure reliability guidance publishes monthly estimates of noncompliance time that correspond to a 30-day month.

Month used for the calculation	Allowed downtime at 99.9%
30-day month (Microsoft’s estimated noncompliance)	43.20 minutes
Average month (this calculator)	43.83 minutes
31-day calendar month	44.64 minutes
28-day February	40.32 minutes

Sources: Microsoft Azure Well-Architected Framework, Amazon Compute SLA, Google Compute Engine SLA

Google also counts only whole minutes: “Partial minutes or intermittent Downtime for a period of less than one minute will not count towards any Downtime Periods.” Read a calculator’s monthly figure as a planning average.

How Do You Calculate Uptime?

Divide the covered minutes by the total minutes. Google’s Compute Engine SLA defines Monthly Uptime Percentage as the total number of minutes in a month, minus the number of minutes of Downtime suffered from all Downtime Periods in a month, divided by the total number of minutes in a month. Two hours of outage in a 30-day month scores 99.72%.

99.9% Uptime Example: Downtime per Year, Month and Day

At the default 99.9%, the calculator treats 0.1% of every period as downtime and applies it to a 365.25-day year of 31,557,600 seconds. Five steps rebuild the panel:

Year: 31,557.6 seconds, which the calculator rounds to 8 hours, 45 minutes and 58 seconds.
Quarter: a quarter of that, 7,889.4 seconds, shown as 2 hours, 11 minutes and 29 seconds.
Month: a twelfth, 2,629.8 seconds, shown as 43 minutes and 50 seconds.
Week: seven days, 604.8 seconds, shown as 10 minutes and 5 seconds.
Day: one day, 86.4 seconds, shown as 1 minute and 26 seconds.

“Nines” reads “three nines”. AWS’s availability table lists 99.9% as 8 hours 45 minutes of maximum unavailability a year, and Microsoft’s table estimates 8.76 hours of noncompliance.

A budget this precise still has to be read against the contract it came from.

What Your Downtime Budget Means

The result from an SLA uptime calculator caps total downtime for the period, so one long outage and many short ones spend it alike. The National Institute of Standards and Technology’s glossary defines availability as “Ensuring timely and reliable access to and use of information.”

An uptime percentage measures one part of that, whether a service answered at all, so a slow or partly broken service can still count as up.

Google’s Site Reliability Engineering book, for one, defines availability for Google’s own services by request success rate instead of uptime minutes. Marc Alvidrez’s chapter gives the example of a system that serves 2.5 million requests in a day with a daily availability target of 99.99%, which can serve up to 250 errors and still hit its target for that given day.

AWS also advises against leaving planned maintenance out of the total time: “this is not advised, as your users will likely want to use your service during these times.” A target helps set expectations and size redundancy; it cannot stop an outage from happening. The calculator has no input for maintenance windows, partial outages or the credits a contract pays; it counts the whole period.

Why Another Calculator Shows a Different Number

Calculators disagree by seconds because they choose different year and month lengths. A 365-day year gives 8 hours, 45 minutes and 36 seconds at 99.9%, against this calculator’s 8 hours, 45 minutes and 58 seconds on 365.25 days. Month length moves the monthly figure too, as the table above shows.

Cloud providers write these percentages into contracts, with their own counting rules.

How AWS and Google Cloud SLAs Measure Uptime

At least 99.99% monthly uptime is the multi-zone compute target in both SLAs. AWS commits commercially reasonable efforts to it. Google sets it as an objective on its Premium Tier outside Mexico and Stockholm. Missing it can earn bill credits, subject to each SLA’s conditions.

AWS’s region-level target applies with all running instances deployed concurrently across two or more AZs in the same region (or at least two regions if there is only one AZ in a given region). AZ stands for Availability Zone. A single instance’s target, on the same commercially reasonable efforts basis, is an Instance-Level Uptime Percentage of at least 99.5%.

On the same Google network service tier (Premium) and regions, the Compute Engine service level objective (SLO) is at least 99.95% for a single memory-optimized instance and at least 99.9% for a single instance of all other machine families.

Provider and scope	Target	Credit if monthly uptime falls short
AWS EC2, Region-Level SLA (all running instances across two or more AZs)	at least 99.99% per monthly billing cycle, on a commercially reasonable efforts basis	10% if less than 99.99% but equal to or greater than 99.0%; 30% if less than 99.0% but equal to or greater than 95.0%; 100% if less than 95.0%
Google Compute Engine, instances in multiple zones (Premium Tier, excluding Mexico and Stockholm)	at least 99.99% per calendar month	10% from 99.00% to below 99.99%, 25% from 95.00% to below 99.00%, 100% below 95.00%

Sources: Amazon Compute Service Level Agreement, Google Compute Engine Service Level Agreement

AWS calculates Region-Level credits as a percentage of the monthly bill (excluding one-time payments such as upfront payments made for Reserved Instances) for Amazon EC2 in the affected AWS region. Google’s credit is a percentage of monthly bill for the respective Covered Service in the Region that did not meet SLO, credited to future monthly bills.

The terms quoted here come from the AWS EC2 SLA as last updated May 25, 2022 and Google’s Compute Engine SLA as last modified March 4, 2025, so check the live versions before relying on them.

Credits come with conditions. AWS applies Service Credits only against future payments for Amazon EC2. At its discretion, it may issue the Service Credit to the credit card you used to pay for the billing cycle in which the Unavailability occurred instead. It also states that “Service Credits will not entitle you to any refund or other payment from AWS.”

To claim one, a customer must submit a claim by opening a case in the AWS Support Center. The request must arrive by the end of the second billing cycle after which the incident occurred. A Region-Level request must also give the dates, times, and affected AWS region of each Unavailability incident, the resource IDs and request logs. Missing information will disqualify you from receiving a Service Credit.

When Google misses the SLO, a customer is eligible for Financial Credits “if Customer meets its obligations under this SLA.” The customer must notify Google technical support within 60 days of becoming eligible. It must also provide log files showing Downtime Periods and the date and time they occurred, or forfeit its right to the credit. Google’s SLA “states Customer’s sole and exclusive remedy for any failure by Google to meet the SLO.”

For a buyer, the SLA sets the compensation for downtime, and the architecture decides how much downtime there is. The AWS vs Azure vs Google Cloud statistics compare the three providers’ market share and revenue.

How Much Downtime Is Allowed per Year at 99.5% Uptime?

A 99.5% target allows 43.83 hours of downtime a year, which the calculator displays as 1 day, 19 hours and 49 minutes, and 219.15 minutes in its average month. AWS measures its single-instance target of at least 99.5% per monthly billing cycle, so a 31-day cycle allows 223.2 minutes.

Stacking services changes the arithmetic again.

Composite SLA: Uptime When Services Depend on Each Other

A workload that needs several services at once inherits the downtime of each. AWS says that with hard dependencies, the invoking system’s availability is the product of the dependent systems’ availabilities, so a system designed for 99.99% with hard dependencies on two other independent systems designed for 99.99% can theoretically achieve 99.97% availability. Microsoft’s guidance treats a composite target the same way, as a product distribution of the contributing factors.

Entering that composite figure in “Agreed uptime” gives 157.79 minutes of downtime a year.

Redundancy, by contrast, raises theoretical availability: in AWS’s example, two independent, redundant components of 99.9% each give an effective availability of 99.9999%. A workload spread across several cloud providers faces the same multiplication. The cloud computing statistics cover how common hybrid and multi-cloud estates have become.

How Many Hours of Downtime Is 99.99% Uptime?

Less than one hour: a 99.99% target allows 52.596 minutes a year, shown as 52 minutes and 36 seconds, and 4.383 minutes in an average month. For comparison, Google’s SRE book puts the same target at up to 52.56 minutes in a year, the figure for a 365-day year.

Is 99.99% Uptime Good?

A 99.99% target matches the multi-zone compute target of at least 99.99% in both SLAs, which AWS pursues with commercially reasonable efforts and Google sets on its Premium Tier outside Mexico and Stockholm. Neither SLA sets that level for a single instance.

In those same terms, Google’s single-instance objectives are at least 99.95% (memory-optimized) and at least 99.9% (other families), and AWS’s is at least 99.5%. Google’s SRE book adds a user’s view: “a user on a 99% reliable smartphone cannot tell the difference between 99.99% and 99.999% service reliability!” It also warns that an incremental improvement in reliability may cost 100x more than the previous increment.

Web hosts advertise uptime guarantees too, and the web hosting statistics cover the levels hosts commonly promise and the causes of hosting downtime.

Sources Used on This Page

Is there anything else my agent or I should know about this page?

Yes. The calculator runs in your browser and nothing you enter reaches our server. It assumes a year of 365.25 days and an average month of one twelfth of that, and it counts every minute of the period, with no allowance for maintenance windows, partial outages or a minimum outage length.

Every figure is the period’s length multiplied by the share of time the uptime percentage leaves uncovered. Three things sit outside the tool: the counting rules in your provider’s own SLA, the service credits a missed target pays, and the combined availability of services that depend on each other, which you work out beforehand and enter as a single figure.

SQ Magazine publishes the page for information. A downtime budget helps you read an SLA and size redundancy; it promises no uptime outcome and cannot stop an outage.

Conclusion

A 99.9% SLA leaves 8 hours, 45 minutes and 58 seconds of downtime a year. Per Google’s SRE book, each additional nine corresponds to an order of magnitude improvement toward 100% availability. Compare levels in the uptime calculator’s “Examples” chips or enter a composite figure, then check the month length and credit terms in your provider’s SLA.

For engineers, the budget helps size redundancy and plan maintenance; for buyers, it shows what an SLA covers before the contract is signed. The internet outage statistics show how often real outages happen and what they cost.