Website uptime monitoring answers one question, over and over: is my website reachable right now? A monitor requests your site on a schedule, records what came back, and tells you when the answer changes. This guide explains how that works, what the results can and cannot tell you, and how to decide what you need.
It is about method. For definitions, see uptime and downtime in the glossary. For hands-on setup, see How to Monitor Website Availability.
What website uptime monitoring is
Monitoring is a loop of four parts:
- Check. A system outside your website requests an address you chose.
- Judge. It decides whether the answer counts as working.
- Alert. If the answer is bad, it tells the people you named.
- Record. Every result is kept, so you can look back.
The first two parts decide how useful the rest is. A monitor that checks the wrong address, or accepts the wrong answers, will report calm while your visitors see errors.
Why availability matters
When a website is unreachable, visitors cannot buy, sign in, read, or contact you. Most owners learn about an outage from a customer, a colleague, or a missing order. Each of these arrives late and tells you nothing about when the problem began.
Monitoring changes two things. You hear about a problem when it starts, and you keep a record of how long it lasted. The record is useful afterwards too: it shows whether a problem is a one-off or a pattern.
How HTTP monitoring works
Most website monitors speak HTTP, the same language browsers use. For each check the monitor:
- Looks up the address in DNS.
- Opens a connection, and for
https://addresses, a secure TLS connection. - Sends an HTTP request, usually
GET. - Reads the status code of the response.
The status code is the verdict. A 200 says the server handled the request. A 503 says the server is up but cannot serve it. No answer at all, because DNS failed or the connection timed out, is a failure too.
Redirects need a rule. If http://example.com sends visitors to https://www.example.com, the monitor can follow the redirect and judge the final answer, or judge the redirect itself. UptimeWire follows a limited number of redirects and judges the final response: a final status from 200 to 399 counts as available, and any other status counts as a failure. A chain that never settles is a failure as well.
What a check actually measures
A check measures one request to one address from one place at one moment. That is narrower than it sounds:
- It measures the address you gave it, not your whole website. A monitor on the home page says nothing about
/checkout/. - It measures the response, not what the page does in a browser. Scripts, images, and third-party widgets are not run.
- It measures one moment. What happened between checks is invisible.
The check also records how long the answer took. See response time for what that number includes and why it differs between tools.
Choosing a monitoring interval
The interval is the time between checks. A shorter interval finds problems sooner, because a failure can only be noticed by a check that runs while it is happening.
| Interval | What it means in practice |
|---|---|
| 1 minute | A problem is noticed within about a minute or two. Suited to sites where minutes cost money. |
| 5 minutes | A reasonable default for most business sites. |
| 15 to 30 minutes | Enough for low-traffic sites where a short outage is tolerable. |
| 1 hour or more | Catches long outages only. A short outage can pass between two checks unseen. |
Two cautions. First, the interval is not the detection time: confirmation (next section) adds a little. Second, shorter is not always better. If a check also triggers heavy work on your server, run it less often or point it at a lighter address.
Plans limit how short an interval can be. In UptimeWire the shortest is 5 minutes on Free, 3 on Starter, and 1 on Business and Agency.
Confirming an outage
Networks are noisy. A single request can fail because of a dropped packet, a brief overload, or a problem on the monitor's side, while the site is fine for everyone else. If every failed check raised an alert, you would learn to ignore alerts.
Confirmation fixes this. The monitor repeats a failed check, a short pause apart, and opens an incident only when the failures continue. UptimeWire works this way, and where a second vantage point is available it can ask that one as well. This costs a little detection time, which is a fair price for alerts you can trust.
Note
Confirmation means an alert does not arrive the instant a site breaks. Detection time depends on the interval, the repeated checks, and how quickly the notification reaches you. No monitor can promise an exact time.
Monitoring from outside
There are two broad ways to watch a system. Google's SRE book calls them black-box and white-box monitoring. Black-box monitoring tests what a user can see, from outside. White-box monitoring reads the system's own signals, such as CPU load, memory, and logs.
Website uptime monitoring is black-box. That is its strength: it sees what visitors see, including failures that your own server cannot report about itself, such as an unreachable network or a broken DNS record. It is also its limit: it tells you that something is wrong, not why.
The two approaches complement each other. External checks say "visitors cannot reach the site". Internal metrics help explain why.
Response time
A slow site is a partly broken site. Tracking response time alongside availability shows trouble before it becomes an outage: a database starting to struggle, a deploy that added a slow query, a server short of resources.
Treat the number carefully. It is the time for a plain request, not the time a page takes to be usable in a browser. Compare it with its own history rather than with another tool's figure.
Certificates, domains, and DNS
A website can fail without the web server being at fault. Three separate things have to keep working:
- The SSL/TLS certificate. When it expires, browsers show a full-page warning. See How to Prevent SSL Certificate Expiration.
- The domain registration. If renewal is missed, the domain stops working, and may be lost.
- DNS resolution. If the name no longer resolves, visitors cannot find the server, however healthy it is.
These fail slowly and then suddenly. They need checks of their own, on their own schedule, because the HTTP check will not warn you in advance. A certificate that expires tomorrow still answers 200 today.
UptimeWire checks the certificate, the domain expiration date, and DNS resolution for every website, separately from the uptime check. Certificate, domain, and DNS warnings go out by email and Telegram.
Incident history and status pages
An incident is a period of confirmed failure, from the first confirmed bad check to recovery. Keeping a history of incidents answers questions that come up later: when did it start, how long did it last, how often does this happen?
A status page is a public page that shows visitors whether your service is working. It saves support time during an outage and builds trust afterwards. Whether you need one depends on your audience. A shop or a SaaS product with customers waiting for answers benefits. A personal blog does not.
What monitoring cannot do
Be clear about the limits, so that a quiet dashboard is not mistaken for proof that all is well.
- A
200is not "it works". A server can answer200while the database is down, the checkout is broken, or the page shows an error message. A plain request check cannot see this. To check for it, the monitor needs to look for something specific in the response, or you need to monitor a deeper address such as a health endpoint. - Only the configured addresses are watched. One address is one address. Monitoring
example.comdoes not covershop.example.comor/api/. Add each one that matters. - It does not replace internal monitoring. It tells you the site is down, not which component failed.
- It is not contractual proof. Numbers from a monitoring tool are an estimate seen from one vantage point. They are useful for your own records, but a Service Level Agreement defines its own way of measuring. See SLA.
- Checks sample time. A one-minute outage between two five-minute checks may never be seen.
Choosing what to monitor
Start from what would hurt most if it broke, not from what is easiest to check.
- List the addresses visitors depend on. The home page, the sign-in page, the checkout, an API endpoint. Each can fail independently.
- Pick an interval for each. The faster the cost of an outage grows, the shorter the interval.
- Decide who is told, and how. Email reaches everyone; a chat channel reaches the on-call person faster. Make sure the alert goes to someone who will see it.
- Add the slow failures. Certificate expiry, domain expiry, and DNS belong on the list.
- Decide whether visitors need a status page.
A practical checklist
- Every important address is monitored, not only the home page.
- The monitored address returns a meaningful answer, not a generic one.
- The interval matches how costly an outage is.
- Alerts reach a person who will act on them.
- Certificate, domain, and DNS checks are on.
- You have tested that an alert actually arrives.
- You review the incident history from time to time.
When you are ready to set this up, How to Monitor Website Availability walks through the steps in UptimeWire.