What an uptime percentage means in minutes of downtime
Uptime targets as minutes per day, week, month and year, how fast one incident uses the budget, and what the minutes mean for your support team.
By the Paperlink AI teamPublished 6 min read
Short answer
Allowed downtime is 100% minus the uptime target, times the length of the period, and in minutes the higher targets leave very little room. One ordinary incident, counted from failure to fix, can use most of a month at a high target. Report the number of incidents and the longest one next to the percentage, and prepare support for the contacts each outage brings.
An uptime target such as 99.5% sounds close to perfect. Written as minutes, it is easier to judge: it allows 7 minutes of downtime a day, or 219 minutes in an average month. This post turns common targets into minutes, then shows how fast one ordinary incident uses that time, and what the numbers mean for the team that answers customers while the service is down.
Uptime targets in minutes
Allowed downtime is (100% minus the uptime percentage) times the length of the period. The table uses the same math as our uptime calculator: a year of 365.25 days and a month of one twelfth of that year. Minutes are rounded down, so each number is the time you can be down and still meet the target.
| Uptime target | Per day | Per week | Per month | Per year |
|---|---|---|---|---|
| 95% | 72 | 504 | 2,191 | 26,298 |
| 97% | 43 | 302 | 1,314 | 15,778 |
| 99% | 14 | 100 | 438 | 5,259 |
| 99.5% | 7 | 50 | 219 | 2,629 |
| 99.7% | 4 | 30 | 131 | 1,577 |
| 99.8% | 2 | 20 | 87 | 1,051 |
Two things stand out. First, the gap between targets is not even. Going from 95% to 99% cuts the monthly budget from 2,191 minutes to 438. Going from 99.5% to 99.8% cuts it from 219 to 87. Each step at the top costs a lot of engineering for a small change in the percentage. Second, at the higher targets the daily number is a few minutes. That is less time than it takes most teams to notice a problem.
How one incident uses the budget
Downtime is not only the time it takes to fix the problem. The clock starts when the service fails, and the minutes before anyone knows count too. Take one ordinary incident, as an example and not a benchmark:
- 3 minutes to detect. The monitor checks every minute and alerts after 3 failed checks in a row, to avoid false alarms.
- 10 minutes to respond. The person on call sees the alert, opens a laptop and finds the cause.
- 25 minutes to fix. A rollback of the last release, then a check that it worked.
That is 38 minutes of downtime. Here is how many incidents like it fit into one month at each target:
| Uptime target | Monthly budget in minutes | Incidents that fit |
|---|---|---|
| 95% | 2,191 | 57 |
| 97% | 1,314 | 34 |
| 99% | 438 | 11 |
| 99.5% | 219 | 5 |
| 99.7% | 131 | 3 |
| 99.8% | 87 | 2 |
At 99.8%, the team can afford 2 such incidents a month. A third one misses the target. That is why higher targets depend on faster detection and automatic recovery more than on fewer bugs: the 3 plus 10 minutes before the fix starts are often the part you can shorten most.
Calendar months are not all the same length
Many agreements measure uptime per calendar month. The same percentage then allows a different number of minutes each month. At 99.5%:
| Month length | Allowed downtime |
|---|---|
| 28 days | 3 h 21 min 36 s |
| 30 days | 3 h 36 min |
| 31 days | 3 h 43 min 12 s |
| Average month (30.44 days) | 3 h 39 min 9 s |
The difference is small, but it matters when a month ends close to the line. Check whether your agreement uses calendar months, a rolling 30 days or the average month, and use the same rule when you report.
The percentage hides the shape of the downtime
One outage of 60 minutes in a month gives 99.8631% uptime. So do 12 outages of 5 minutes each. The number is the same, but customers feel them very differently. One long outage is a bad afternoon and a clear story. Many short ones feel like a service you cannot trust, and each one may break a checkout, an upload or a login in the middle of the work.
When you report uptime, report the number of incidents and the longest one next to the percentage. Both are easy to count, and they show what the percentage hides.
What counts as down
Agreements often leave out announced maintenance. That choice changes the number. Suppose a service has one unplanned outage of 45 minutes and a 120-minute maintenance window in the same month:
- Maintenance excluded: 99.8973% uptime.
- Maintenance counted: 99.6235% uptime.
Both numbers are honest, as long as you say which one you report. Other choices change the number too: whether a slow page counts as down, whether a feature that fails while the rest works counts, and where the monitor runs. Write those rules down before you publish a target.
What the minutes mean for your support team
Every minute of downtime is also a minute when customers write to you. Contacts during an outage rise fast, and many of them ask the same three questions: is it down, is it my fault, and when will it be back. A few habits keep the queue under control:
- Post a status update within the detection and response window. The first update can be one line: what is affected and when the next update comes.
- Keep a help page for outages. Say where the status page is, what customers can do while they wait, and whether they lose any data.
- Prepare one reply template. Link the status page and promise an update by a set time, so agents do not write the same answer from scratch.
- Plan staff for the spike. The Erlang calculator shows how many agents a burst of contacts needs.
Paperlink AI is a customer support chatbot that answers only from the documents you upload and the website pages you import. If your outage help page is one of them, the bot can answer the "what should I do" questions from it. Imported pages update on a schedule, and you can select Update now to read a changed page again. See Import a website. When a question is not covered, the bot says so and shows your support contact, so the customer still reaches your team.
To convert your own targets, outages and component uptimes, use the uptime calculator. It runs in your browser.