99.9% uptime: what agencies can promise their clients
99.9% uptime allows about 43 minutes of downtime a month, or about 8 hours 46 minutes a year. Those figures use a 30-day month and a 365-day year.
99.9% uptime allows 43.2 minutes in a 30-day month
The exact monthly figure is 43.2 minutes, or 43 minutes and 12 seconds. That is the total downtime allowed, whether it happens in one outage or several.
All times in the table are minutes. It uses fixed 24-hour days, a seven-day week, a 30-day month and a 365-day year. No maintenance or other time has been left out.
| Uptime target | Day (min) |
Week (min) |
Month (min) |
Year (min) |
|---|---|---|---|---|
| 99% | 14.4 | 100.8 | 432 | 5,256 |
| 99.5% | 7.2 | 50.4 | 216 | 2,628 |
| 99.9% | 1.44 | 10.08 | 43.2 | 525.6 |
| 99.95% | 0.72 | 5.04 | 21.6 | 262.8 |
| 99.99% | 0.144 | 1.008 | 4.32 | 52.56 |
Google's SRE availability table gives the same monthly allowances. These figures have been recalculated so the smaller values are not rounded away. Decimal minutes are not minutes-and-seconds notation: 1.44 minutes means 1 minute and 26.4 seconds.
A monthly promise applies to the monthly column. It does not also promise the daily or weekly limits, and meeting a yearly target does not mean every month passed.
- 99%432 min
- 99.5%216 min
- 99.9%43.2 min
- 99.95%21.6 min
- 99.99%4.32 min
30-day month. Linear scale, longest bar: 432 minutes. Calculated from Google SRE's availability table. Source checked September 28, 2026.
A year of 99.9% uptime allows about 8 hours 46 minutes
The exact yearly figure is 8 hours, 45 minutes and 36 seconds, or 525.6 minutes. For a 30-day month, the allowance is 0.72 hours.
A calendar month is not always 30 days. At 99.9%, a 28-day period allows 40.32 minutes and a 31-day period allows 44.64 minutes. Dividing the yearly total by 12 gives 43.8 minutes per month on average, not the allowance for every calendar month. Match the calculation to the period in your client agreement.
To calculate another period:
Allowed downtime = minutes in the period x (1 - uptime percentage / 100)
For a 30-day month at 99.9%, that is 43,200 x 0.001 = 43.2 minutes.
Why 5-minute checks can't prove 99.99%
A monitor that checks every 5 minutes can miss any outage shorter than 5 minutes. At 99.99%, your whole 30-day monthly allowance is about 4.3 minutes.
Here is an imagined example with one check every five minutes and no other records:
- The check passes.
- An outage begins.
- The service recovers.
- The next check passes.
The site was down for 4 minutes and 30 seconds. That is longer than the exact monthly limit of 4 minutes and 19.2 seconds, but both checks passed. From those two results alone, you cannot tell whether the site stayed up or went down between checks.
A monitor can still show 99.99% in a report. That number describes what its checks recorded, not everything that happened between them. Google's SRE book treats how often you measure as part of defining the measure itself.
Checking more often makes the gaps smaller. Checks from several locations at the same moment still leave the same time gap. Logs or other request records can add evidence between scheduled checks.
A passing homepage check does not prove the checkout works
Google's monitoring chapter names a 200 response with wrong content as a possible error. A passing homepage check does not prove that a client's checkout completed an order. The guide to what an uptime check can establish explains how to choose what each check covers.
Google's chapter on service targets also describes availability as the share of requests that succeed. That is different from time online. A failed request during a busy period and a minute of downtime are not the same unit, so a request-success target cannot simply be read from the minutes table.
A 99.9% client promise you can copy and adapt
Starting point to adapt, not legal wording. Fill in every bracket with terms your service and monitoring setup can support.
We aim for 99.9% uptime each calendar month ([your time zone]). We check [pages or journeys] every [interval] from [locations].
Downtime starts when [for example, two checks in a row fail] and ends when [for example, the next check passes]. If a check doesn't run, we [count it as up / count it as down / leave it out].
Planned maintenance, announced [X] hours ahead, is not counted. We remove that time from both the downtime total and the time used to calculate uptime, and list the excluded periods in the report.
If we miss the target, [agreed action or credit].
That last line matters. Google's SRE book distinguishes a service target from an SLA with consequences for missing it. Keep a promise about when a person will respond separate from the check schedule.
Once you have chosen the pages and check interval, compare documented monitoring costs for your client-site count. The calculator compares plan costs, not whether a provider can meet your agreement.
Sources and calculation notes
Based on Google's Site Reliability Engineering book and calculations using the periods in the table. WatchfulStack has not used or tested any monitoring product.
- Google SRE: Availability Table. Time-based downtime allowances and the difference from counting failed requests. Checked September 28, 2026.
- Google SRE: Service Level Objectives. What is measured, how often, over which period, and the difference between a target and an SLA. Checked September 28, 2026.
- Google SRE: Monitoring Distributed Systems. Check scope, measurement detail and errors despite a successful HTTP status. Checked September 28, 2026.