Availability checks · Beginner · 20 minutes of setup
How to monitor website uptime — A 200 Proves the Web Server Answered, and Nothing Else
Your monitor says the site is up, your customer says it is broken, and both of them are telling the truth about different things.
The short answer
Probe something that proves the site works, because a status 200 only proves the web server answered. A WordPress site with an unreachable database frequently returns 200 with an error page inside it, and a naive check calls that uptime. Add a keyword match on text that can only appear when the page rendered properly, and point the check at the page that earns money rather than the homepage.
The second half of monitoring is latency. Response time drifting upward for a fortnight is the signal that precedes most outages, and it is visible long before availability moves. This runbook covers probe placement, check interval, confirmation from a second location so one flaky node cannot page you at three in the morning, and certificate expiry as a free extra.
By the HostingFast team · Reviewed 24 August 2026
Beginner
Reader level
Quick
Time to allow
5
Stages in order
24/7
Help on shift
Twenty minutes of setup, one external service, and no software on your own server. Everything here works on a free monitoring tier; the value is in what you point it at and what you do with the alert, not in what you pay.
Two outputs to aim for. First, an alert you will actually notice within minutes, routed to a channel that interrupts you. Second, a response-time chart you look at monthly, because that chart is where the warning lives.
What a status code hides
A 200 means the web server produced a response. It does not mean the database answered, the cache was warm, the certificate validated, or the page contained anything a customer could use. Plenty of fatal application errors are served with a 200 and a stack trace, and every availability graph built on status codes alone reports those as perfect health.
The fix is content verification: give the monitor a string that can only exist on a correctly rendered page — a product name, a footer line, an element only the template outputs after a successful query. Now the check fails when the page is broken rather than when the server is off.
Where the probe stands, and how often
The monitor must live somewhere other than the infrastructure it watches, because a network-level failure takes the internal probe down with the site and reports nothing. External is not a preference here, it is the entire qualification for the job.
A one-minute interval catches a five-minute outage; a five-minute interval might miss it entirely and will certainly under-report its length. Pair that with confirmation from a second location before alerting, so a single flaky probe node produces a note rather than a phone call at three in the morning.
Response time is the early warning
Availability is binary and late. Response time is continuous and early: a page that answered in 400 ms in March and 1,400 ms in May is telling you about a growing table, a leaking plugin or a neighbour's load long before it starts returning errors. Set a threshold alert on latency as well as on failure.
Read the monthly history rather than individual incidents. Repeated micro-outages clustered at the same hour point at a cron job, a backup window or a scheduled task; one isolated blip on a Tuesday afternoon usually tells you nothing worth chasing. Our own platform targets 99.9% uptime and is monitored around the clock, which gives your figures something to be compared against.
Probe the transaction, and the certificate
For a store, monitor the checkout, not the front page. A keyword check on the cart or checkout template watches the pipeline that takes money; the homepage can stay perfectly healthy while the payment path is down. Pick the URL by what it costs you when it fails.
Most monitors will also watch certificate expiry and DNS resolution for nothing extra, which covers two failure modes that produce a working server and an unreachable site. Our SSL reissues itself automatically before expiry, so that alert should stay quiet — which is exactly what makes it useful if it ever fires.
What we watch from our side
The platform targets 99.9% uptime and is monitored around the clock by people who can act on it, which is the baseline your own external monitor is measuring against. Your monitor answers a different question from ours: it watches your application, not our infrastructure.
Daily backups on every plan, with restores you run yourself from the panel rather than raising a ticket.
- 99.9% uptime as the target, watched around the clock
- Free SSL that reissues before it can expire
- Restores you run yourself the moment a check goes red
- Engineers reachable at whatever hour the alert arrives
Why HostingFast
Standard on every plan
Checks that can actually fail
A keyword match means the monitor notices a broken page, not just a stopped server — which is the failure mode that actually happens.
Alerts you will notice
Routing is treated as part of the setup. An alert seen four hours late is a history lesson, not a warning.
Latency as the leading indicator
Response-time thresholds catch the slow slide toward an outage weeks before availability moves at all.
Fewer false pages
Confirmation from a second location before alerting stops one flaky probe node from waking you for nothing.
Aimed at the money path
The checkout gets the probe, because that is the URL whose failure has a price attached.
Certificates and DNS included
Two more ways to have a working server and an unreachable site, covered by the same twenty minutes of setup.
Quick Start
From order to online
- 1
Put the probe outside your hosting
A free external service checking every minute from infrastructure unrelated to yours. Internal probes die with the network they live on and report nothing.
- 2
Add a keyword the page can only render
Pick a string that appears solely on a correctly built page. Now a fatal error served with a status 200 fails the check instead of passing it.
- 3
Point it at the transaction
Checkout, login or the booking form — whichever URL costs you money when it breaks. The homepage is the least informative page you could watch.
- 4
Set a latency threshold too
Alert on response time as well as failure, then review the monthly chart. That trend is where outages announce themselves in advance.
- 5
Route alerts and require confirmation
Email plus a channel that interrupts, with a second-location confirmation before it fires. Noticed in two minutes, and not woken for a single flaky probe.
Built In
Loaded onto every plan
- 99.9% uptime as the target, monitored around the clock
- Human support on duty every hour of every day
- Daily backups on every plan, with restores you run yourself from the panel
- Free SSL on every plan, reissued automatically before it can expire
- LiteSpeed caching compiled into the server, not bolted on by plugin
- NVMe SSD storage on every tier, including the entry plan
- Staging environments for rehearsing a change before it ships
- cPanel — the control panel most of the industry already runs
- DDoS filtering absorbed out at the network edge
- In-place account upgrades, with no migration when you change plan
Frequently Asked
What people ask us most often
What check interval actually catches a five-minute outage?
One minute. A five-minute interval can miss a five-minute outage completely and will always under-report its duration, which matters when you are trying to correlate an incident with a deploy or a cron job. Most free tiers offer one-minute checks on a small number of monitors, which is the right place to spend that allowance.
How do I stop one flaky probe node paging me at three in the morning?
Require confirmation from a second location before the alert fires, and set a short retry delay. A genuine outage fails from everywhere; a transient routing problem fails from one node and clears on the retry. That single setting is the difference between a monitor you trust and a monitor you mute.
Should I be alerting on response time as well as availability?
Yes, and it is the more useful of the two. Availability tells you the site is already down; latency drifting from 400 ms to 1,400 ms over a fortnight tells you it is going to be. Set a threshold well above your normal figure so it catches a trend rather than every busy afternoon.
What exactly does a status 200 fail to tell me?
That the page is usable. Many application errors are returned with a 200 and an error message in the body, so a code-only check reports perfect uptime while customers see nothing they can buy from. Content verification closes that gap, and it is the single most valuable setting on the whole monitor.
Keep reading
How to Set Up DKIM Signing
Sign outgoing mail so tampering and spoofing both become visible to the receiving server — intermediate, roughly 15 minutes.
How to Read Your Website Statistics
Read traffic straight from the server's own logs, with no tag, no script and no consent banner in the way — beginner, roughly 20 minutes.
Uptime (Glossary)
What an availability figure does and does not promise, and how the maths works out in minutes.
WordPress Hosting
WordPress on LiteSpeed and NVMe, with staging clones and daily backups included.
Dedicated Cloud
Reserved resources with cloud flexibility — the next gear up from a VPS.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Watch a platform worth monitoring.
99.9% uptime as the target, watched around the clock, with free auto-renewing SSL and restores you run yourself.
View WordPress Hosting plans