--- title: "Uptime Calculator" date: 2026-10-05 author: "Robert A. Lee" featured_image: "https://sqmagazine.co.uk/wp-content/uploads/2026/10/uptime-calculator.jpg" --- # Uptime Calculator 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. Uptime Calculator Examples Reset 99.9% (three nines) 99.95% 99.99% (four nines) 99.999% Down 45 minutes this month Three services in series Business hours, 9 to 6 Work out Downtime allowed Uptime achieved Several services Agreed uptime % The availability your SLA promises, for example 99.9 for three nines. Downtime observed Downtime unit Seconds Minutes Hours Over A day A week A 28-day month (February) A 30-day month A 31-day month A quarter (91.31 days) A year (365.25 days) Uptime of each service (%) Separate with commas, for example 99.99, 99.95, 99.9 for a host, a database and a payment provider. How they combine All neededEvery service is needed (in series) Any one will doAny one copy is enough (redundant) Measured over Around the clock Set hours Hours a day hours Days a week days Downtime allowed per year 8h 45m 58s Copy An uptime of 99.9% allows 8h 45m 58s of downtime a year, or 43m 50s in an average month. Uptime achieved99.8958% Combined uptime99.8401% Downtime allowed per year8h 45m 58s Against your targetMissed 99.9% by 1m 48s Downtime your target allows in this period43m 12s Common levels met99.5% met; 99.9% missed Weakest service99.9% (lowest of 3) Against your targetBelow 99.9%: it allows 26m 16s more downtime in an average month Per quarter2h 11m 29s Per average month (30.44 days)43m 50s In a 28-day February40m 19s In a 30-day month43m 12s In a 31-day month44m 38s Per week10m 5s Per day1m 26s Ninesthree nines Copy all details Save scenario Share result Download CSV Saved scenarios Saved in this browser only. Each column is recalculated whenever the page loads. Common SLA levels | Uptime | Per day | Per month | Per year | |---|---|---|---| How this is calculated How it worksAvailability is uptime divided by total time, the measure in the [AWS Well-Architected reliability pillar (opens in new window)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html). 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 coveredNo 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. CorrectionsReport a wrong result to [media@sqmagazine.co.uk](mailto:media@sqmagazine.co.uk?subject=Correction%3A%20Uptime%20Calculator); 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. FeedbackHow useful was this tool? The figures shown are the worked example. Enable JavaScript to calculate with your own numbers. ## 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. 1. 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. 2. Start with “Downtime allowed per year”, then read “Per quarter”, “Per month”, “Per week” and “Per day”. 3. Check “Nines”, which names a value made only of nines, such as “three nines” for 99.9, and stays blank when other digits appear. 4. 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](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) 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](https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics) 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: 1. Year: **31,557.6 seconds**, which the calculator rounds to 8 hours, 45 minutes and 58 seconds. 2. Quarter: a quarter of that, **7,889.4 seconds**, shown as 2 hours, 11 minutes and 29 seconds. 3. Month: a twelfth, **2,629.8 seconds**, shown as 43 minutes and 50 seconds. 4. Week: seven days, **604.8 seconds**, shown as 10 minutes and 5 seconds. 5. 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](https://csrc.nist.gov/glossary/term/availability) 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](/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](/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](/web-hosting-statistics/) cover the levels hosts commonly promise and the causes of hosting downtime. ## Sources Used on This Page - [Amazon Compute Service Level Agreement](https://aws.amazon.com/compute/sla/). - [Compute Engine Service Level Agreement](https://cloud.google.com/compute/sla). - [Reliability Pillar: Availability](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html). - [Architecture strategies for defining reliability targets](https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics). - [Embracing Risk](https://sre.google/sre-book/embracing-risk/). - [Glossary: availability](https://csrc.nist.gov/glossary/term/availability). ## 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](/internet-outage-statistics/) show how often real outages happen and what they cost. ## More Security Calculators [All security calculators (2) →](https://sqmagazine.co.uk/tools/) - [ Download time 50 GB at 300 Mbps 24m 41s DSL 10 Mbps 12h 20m 44sFiber 1 Gbps 7m 24s Security In your browser Download Time Calculator How long a file takes at your connection speed. 270 MbpsEffective speed → ](https://sqmagazine.co.uk/download-time-calculator/) - [ Network 192.168.1.10/24 192.168.1.0/24 Network In your browser IP Subnet Calculator Network, broadcast, host range and mask for any IPv4 block. 254Usable hosts → ](https://sqmagazine.co.uk/subnet-calculator/)