You can measure a website in a hundred ways, and most dashboards will happily show you all of them. In practice only a handful of numbers change what you do. This guide covers those, what each one tells you, and what is worth acting on.
1. Availability (uptime)
Uptime is the share of time your site was working, usually shown as a percentage over a month or a year. It is the headline number, and the easiest to misread, because the percentages look so similar. The difference between them is not:
| Uptime | Down per month | Down per year |
|---|---|---|
| 99% | about 7 hours 18 minutes | about 3 days 15 hours |
| 99.5% | about 3 hours 39 minutes | about 1 day 20 hours |
| 99.9% | about 44 minutes | about 8 hours 46 minutes |
| 99.99% | about 4 minutes 23 seconds | about 52 minutes |
When a host promises “99.9% uptime”, this is what they are promising: up to 44 minutes of downtime a month is within the deal. Measure it yourself rather than taking the promise on trust, and read it alongside the next metric, because ten one-minute outages and one ten-minute outage give the same percentage but feel very different to your visitors.
2. Incidents, and how long they last
An incident is one continuous period of the site being down. Two numbers come from them:
- How many. Frequent short incidents point to something unstable: an overloaded server, a flaky dependency, a deploy process that breaks things.
- How long. Duration is what visitors experience. The industry names for the averages are mean time to detect (how long before you knew) and mean time to recover (how long before it was fixed). Monitoring shrinks the first directly, and the incident history shows you the second.
If you track only one thing besides uptime, track incident duration.
3. Response time
Response time is how long the site takes to answer a request. It matters for two reasons. Slow sites lose visitors, and search engines take speed into account. Less obviously, response time is an early warning. Sites rarely go from healthy to dead in a moment; they get slower first as a database grows, a cache stops working or a server runs short of memory.
Watch the trend rather than any single reading. One slow response means little. A response time that has crept up week after week means something is going wrong, and you can fix it while the site is still up.
Be wary of averages. A site that is fast nine times out of ten and painfully slow the tenth time has a perfectly good average and an unhappy visitor one time in ten.
4. Status codes
Every response carries a three-digit status code, and the first digit tells you the story:
- 2xx means success. This is what a healthy page returns.
- 3xx means redirect. Normal, but a page that redirects in a loop never loads.
- 4xx means the request was wrong. A 404 on a page that should exist, or a 403 where the page should be public, is a fault even though the server is running.
- 5xx means the server failed. A 500, 502, 503 or 504 means visitors are seeing an error page.
A monitor that only checks whether the server answers will happily report “up” while every visitor sees a 500 error. Make sure yours judges the status code, not just the connection.
5. SSL certificate health
An expired or invalid certificate is one of the most common avoidable outages. Browsers replace the page with a security warning, and most visitors will not click through. The certificate may be valid on the day you set it up and expire a year later, when nobody is thinking about it, so it is the kind of failure monitoring is ideal for. A check that treats an expired or invalid certificate as down will tell you the day it happens.
6. DNS and reachability
Before a browser can load your site, your domain has to resolve to a server, and the server has to accept the connection. A lapsed domain, a mistaken DNS change or a refused connection all stop the site completely, and none of them shows up in your server’s own logs, because the visitor never reached it. Checking from outside, as a visitor would, catches the problems that checking from inside cannot.
What to leave for later
There is plenty more you can measure: page weight, time to first byte, Core Web Vitals, error rates by page. They are worth looking at once the basics are covered. If you are starting out, three things will give you most of the benefit:
- Know straight away when the site is down.
- Keep a history of incidents and their length.
- Watch response time for a slow upward trend.
What Pingvella records
Each website check is requested every 5 minutes. A non-2xx response (after redirects), a timeout, a refused connection, an unresolvable address or an invalid certificate counts as down. Every request records its response time, and every outage is kept as an incident with its start and end, with an uptime chart built from them. You can read more about website monitoring, or see how a check works from start to finish.