How to Read Website Uptime Reports (and Explain Them)
An uptime report is a pile of numbers: a percentage, an average response time, a list of incidents, a chart with spikes. Read carelessly, it either causes panic over nothing or hides a slowly growing problem. This guide shows how to read each part correctly, why percentiles tell you more than averages, how to find patterns in the history, and how to turn it all into a summary a non-technical manager can act on.
Start with the uptime percentage — and its denominator
Uptime percentage is the share of the period during which checks found the site up. The number only means something when you translate it into time:
| Uptime | Downtime per 30-day month | Downtime per year (365 days) |
|---|---|---|
| 99% | 7 h 12 min | 3 days 15 h 36 min |
| 99.5% | 3 h 36 min | 1 day 19 h 48 min |
| 99.9% | 43 min 12 s | 8 h 45 min 36 s |
| 99.95% | 21 min 36 s | 4 h 22 min 48 s |
| 99.99% | 4 min 19 s | 52 min 34 s |
(The often-quoted "43 minutes 49 seconds" for 99.9% uses an average month of 30.44 days; the table uses a 30-day month.) The detailed math and what each level costs to achieve are in uptime percentage explained.
Three things to check before trusting the figure:
- The check interval. With checks every five minutes, a site that is down for three minutes between two checks may never be seen as down at all, and a recorded outage is only accurate to about one interval. A 99.98% month on five-minute checks is a good sign, not a precise measurement.
- The fail threshold. If an incident is only opened after three consecutive failures, short blips are filtered out of the alerting by design. Check whether the report counts those blips separately (as "unstable" or short-outage events) or ignores them.
- Maintenance windows. Many tools exclude planned downtime inside a maintenance window. That is fair for an internal report, but say so if you share the number externally. In Uptime Monitor, checks logged during a maintenance window count as not up in the uptime percentage, so account for them yourself if you want planned work excluded.
Averages vs percentiles: a worked example
Response-time reports usually show an average, and the average is the least useful number on the page. Here is why, with twenty checks from one afternoon:
- 18 checks came back in about 210 ms each (some 190, some 230 — it averages out to 210).
- 2 checks took 2,900 ms and 4,100 ms, because a backup job was running.
Now the three common summaries:
| Statistic | How it is computed | Result |
|---|---|---|
| Mean (average) | (18 × 210 + 2,900 + 4,100) ÷ 20 = 10,780 ÷ 20 | 539 ms |
| Median (P50) | Middle of the sorted list | ≈ 210 ms |
| P95 | Sort all 20 values; take the 19th (95% of 20) | 2,900 ms |
The mean of 539 ms describes no request that actually happened: every visitor got either about 210 ms or about 3–4 seconds. The median says the typical experience is fine. The P95 says one request in twenty is very slow — that is the number that explains the support ticket saying "the site sometimes hangs".
P95 (95th percentile) means "95% of measurements were at or below this value". It focuses attention on the slow tail without being dominated by a single extreme outlier the way a maximum is. Tools differ slightly in how they interpolate between values, especially with small samples, so compare P95 within one tool over time rather than across tools.
A practical reading rule: median tells you about normal operation; P95 tells you about the bad moments; a rising gap between them means something intermittent is going on.
Spotting patterns in the history
A single spike is rarely worth investigating. A spike that repeats is almost always a cause you can find. Look at the response-time chart over at least a week and ask:
Does it happen at the same time every day?
Slowdowns or short failures at a fixed hour — often at night — usually point to scheduled work on the server: database backups, log rotation, search index rebuilds, cron jobs that import data, or a cache that is purged and rebuilt. Compare the time with crontab -l for each user, files in /etc/cron.d/, and systemctl list-timers. Remember to account for time zones: the monitoring dashboard and the server may not use the same one.
Does it line up with deploys?
If response times step up after a particular day and stay up, compare the date with your deploy history. A step change that persists is a regression — a new query, a disabled cache, a heavier page. A short spike right after each deploy that settles within minutes is usually cold caches warming up, which is normal unless it is long enough to cause failures.
Does it follow traffic?
Slowness on weekday business hours or during a campaign, and none at night, suggests capacity limits: not enough PHP-FPM workers, database connections or CPU. That is a scaling question, not a bug.
Is it random and short?
Brief failures scattered without a pattern — one failed check, then fine — can be network noise, but if they become frequent, they are often an early sign of something like a process restarting under memory pressure. Our article on intermittent downtime and flapping sites covers how to chase these.
Reading the cause breakdown
Good reports classify each failure by cause instead of lumping everything as "down". The cause tells you who needs to act:
| Cause | Usually means | Who looks first |
|---|---|---|
| DNS error | Name did not resolve: DNS provider, registrar, or a bad record | Whoever manages the domain |
| Connection error / timeout | Server unreachable, firewall, overloaded host, network problem | Hosting / infrastructure |
| SSL error | Expired or misconfigured certificate | Whoever manages certificates |
| Server 5xx | Application or upstream failure (500, 502, 503, 504) | Developers / backend |
| 404 / other 4xx | URL removed, routing changed, access rules blocking the checker | Developers / content |
| Keyword missing | Page loads but content is wrong: error page, empty template, defacement | Developers / content |
If most of a month's downtime is a single cause, that is where improvement effort should go. Ten short server_5xx incidents point at application stability; one long connection-error incident points at hosting.
Reporting to non-technical stakeholders
Managers and clients do not need P95 definitions. They need to know whether the site was available, whether customers were affected, and what is being done. A one-page monthly summary works well:
- Headline: "The site was available 99.94% of the time in October — about 27 minutes of downtime across two incidents."
- Incidents in plain language: when, how long, what users saw, cause, and fix. "Oct 14, 02:10–02:28: the site showed an error page. The database server ran out of disk space during a backup. Old backups are now removed automatically."
- Speed in one sentence: "Typical page response stayed around 0.3 seconds; the slowest 5% of checks were under 1.2 seconds, an improvement on September."
- Trend: compare with the previous month or quarter, not with an abstract ideal.
- Next steps: at most three concrete actions.
Avoid quoting the average response time, avoid unexplained percentages with many decimal places, and never present 99.9% as "almost perfect" without saying it allows about 43 minutes of downtime a month.
FAQ
What is a good uptime percentage?
It depends on what downtime costs you. Many small business sites run at 99.9% or better on decent hosting; services that people depend on around the clock aim higher and need redundancy to get there.
Why does my report show 100% uptime when users had problems?
Usually because the problem was shorter than the check interval, happened on a page you do not monitor, or returned a 200 status with broken content. Shorter intervals, more monitored URLs and keyword checks close those gaps.
Should I use P95 or P99?
P99 needs many samples to be stable; with one check per minute you get about 1,440 a day, which is fine for a monthly P99 but noisy for an hourly one. P95 is a more robust default for synthetic monitoring.
Checklist for reading any uptime report
- Convert the uptime percentage to minutes of downtime for the period.
- Note the check interval, fail threshold and maintenance exclusions.
- Read median and P95 response time; ignore the mean.
- Look for repeating times of day and step changes after deploys.
- Group downtime by cause and fix the biggest bucket first.
- Summarize for stakeholders in minutes, incidents and next steps.
Uptime Monitor's dashboard shows uptime rings, response-time charts, short-outage badges and a probable cause for every failed check, and you can export the raw check data as CSV or JSON for your own analysis. Plus and Professional add PDF executive reports for stakeholders, with median and P95 response times, and keep 90 and 180 days of history; compare plans on the pricing page.
