Monitoring your own site
The point of monitoring is not to know that your site is up. It is to find out before your customers do - And that requires checking the right thing, from the right place, at the right interval.
The short version
- Monitor a real endpoint that exercises your dependencies, not a static home page.
- Check from more than one location - A single vantage point cannot see a regional problem.
- Alert on two consecutive failures, never one, or you will train yourself to ignore alerts.
- Monitor certificate expiry and domain expiry. Both cause total outages and both are trivially preventable.
Most monitoring setups check that a home page returns 200 and stop there. That catches a server being off and essentially nothing else - And a server being off is the failure mode you were least likely to miss.
Useful monitoring answers a harder question: Is the thing my users need actually working?
Check something real
A static home page served from a CDN will return 200 long after your database has gone. It tests almost nothing.
Build a health endpoint that exercises the path that matters: Connect to the database and run a trivial query, touch the cache, confirm any critical third party is reachable. Return a structured response with per-dependency status, and a non-200 code when something essential is broken.
{
"status": "ok",
"database": "ok",
"cache": "ok",
"payments_api": "degraded",
"version": "2026.9.19"
}Two cautions. Make it cheap - It will be called constantly, and a health check that runs an expensive query becomes a load source. And do not make it so strict that a non-essential dependency takes your whole service out of the load balancer pool; distinguish "I cannot serve requests" from "something is degraded".
Beyond a health check, monitor the journeys that matter: Can a user sign in, can a product page render, can a search return results. A synthetic transaction that performs a real login catches an entire class of failure that no status code will.
Check from more than one place
A single vantage point cannot distinguish "the site is down" from "the route between this checker and the site is down". Two or three locations, on different networks, resolves that immediately: If one reports a failure and the others do not, you have a network problem rather than an outage.
This is a real limitation of this site's own monitoring, and we say so - A single-location check every 20 minutes cannot see regional problems. If you are monitoring something you own, multi-location is worth the small extra cost.
Interval
The check interval is the upper bound on your detection time. Checking every five minutes means an outage can run for five minutes before you know.
Reasonable defaults: Every minute for anything transactional, every five minutes for a normal business site, every fifteen for something internal. Do not go below a minute unless you genuinely need it - You are adding load and the marginal detection benefit is small.
Alert on two failures, never one
The most important rule in this article.
Networks are noisy. A single failed request can be a route flap, a dropped packet, or a load balancer restarting one node. If you page a human on every single failure, you will get woken at 3am for nothing, and within a month you will be ignoring alerts - Which is far more dangerous than not having them.
Require two consecutive failures, ideally from different locations. It costs you one interval of detection time and removes almost all false positives. This site applies exactly that rule to itself: A failed check is re-probed and only a confirmed second failure records an outage.
What to monitor beyond uptime
Certificate expiry. Alert at 30 and 14 days. An expired certificate is a total outage with an entirely preventable cause, and the usual reason it happens is that automated renewal failed silently.
Domain expiry. Alert 60 days out. Rarer and considerably worse - Recovering a lapsed domain is not always possible.
Response time trend. A site getting steadily slower over weeks is a problem developing. Alert on a sustained change rather than a single slow response.
Content, not just status. Check that a known string appears in the response. A page that returns 200 while rendering an error is invisible to status-code monitoring.
Background jobs. A cron that stops running fails silently by definition. Use a dead-man's-switch: The job pings a URL on success, and you are alerted when the ping stops.
Disk space. Boring and responsible for a remarkable share of outages. A full disk breaks things in ways that look nothing like a storage problem.
Notification
Match the channel to the severity. Email for informational, chat for degradation, phone or push for a real outage. If everything arrives in the same channel, everything gets the same amount of attention, which is none.
Always configure a recovery notification. An alert with no "resolved" is worse than no alert, because you cannot tell what is still broken.
And consider where your alerting itself lives. If your monitoring runs on the same infrastructure as the thing it monitors, a regional failure takes both.
A sensible starting point
You do not need a platform to begin. A scheduled script that requests your health endpoint, checks the response, and sends a message on two consecutive failures is maybe thirty lines and catches most of what matters.
Add a free external service for a second vantage point - Several offer a handful of monitors at no cost, which is enough for a small site. Add certificate and domain expiry checks, which are trivial and prevent the two most embarrassing outages there are.
Then, and only then, worry about dashboards.
Questions people ask
What should a website health check actually test?
Something real: A database query, the cache, and any critical third party - Not just that a static home page returns 200. A CDN-served home page will keep returning 200 long after the database has gone, so it tests almost nothing.
How often should I check my website is up?
Every minute for anything transactional, every five minutes for a normal business site. The interval is the upper bound on your detection time, but going below a minute adds load for very little marginal benefit.
Should I get an alert on every failed check?
No. Require two consecutive failures, ideally from different locations. A single failed request is usually network noise, and alerting on every one trains you to ignore alerts - Which is far more dangerous than not having them.
What else should I monitor besides uptime?
Certificate expiry (alert at 30 and 14 days), domain expiry (60 days), response time trends, the actual content of the page rather than just its status code, background jobs via a dead-man's switch, and disk space.
Read next
Synthetic vs real user monitoring
The difference between synthetic checks and real user monitoring, what each catches, and why serious operations run both.
How status pages work
Why official status pages lag user reports, how they are built, and how to read one properly - Including what a green banner does not mean.
Alert fatigue
Why too many alerts is more dangerous than too few, and how to design alerting that people still respond to after six months.
What uptime percentages mean
The uptime nines table, what each level costs to achieve, and why how uptime is measured matters more than the number itself.