Is the Site Up? Uptime Monitoring, Alerts and Incidents
How fast a business notices its own site is down; setting up uptime monitoring, an alert chain and a post-incident review that actually gets read.
rabbitclip teamPublished: 4 min read
Short answer
Uptime monitoring is an external check that runs on a schedule and records whether a website or app actually responds. A basic check only looks at whether the homepage loads; a more reliable setup tests a real transaction, checkout, login, a form submission, on the same schedule. The point is to notice an outage before a customer does, and that only works if an alert is defined in advance: who it reaches, on which channel, within what time.
A workwear manufacturer's checkout page starting to throw errors on a Sunday morning can go unnoticed for hours if a customer complaint is the first sign of it. A check that monitors the checkout flow itself catches the same fault within minutes and notifies the right person; the difference sits between an hours-long loss and a few minutes of response.
What does uptime monitoring actually measure?
Uptime monitoring is a record of whether a server or page, queried from an external check point on a schedule, usually every one to five minutes, responds at all. The response needs to both exist and carry the expected content, the right status code, a specific piece of text on the page; a server simply being reachable is not enough on its own, the page needs to actually work.
This kind of check catches a server that has gone down entirely or stopped responding, but it does not always catch a slowdown, a partial error, or an issue that only shows up in one browser. That is why uptime monitoring sits alongside error tracking and performance monitoring, not in place of them.
Which check catches which problem?
Different check types cover different risks; choosing one does not make the others unnecessary.
- Ping/HTTP check: whether the server responds at all, within seconds
- Content check: whether the page loaded correctly, based on a specific text string or status code
- Synthetic check: whether a multi-step process such as checkout, login or a form submission works end to end
- SSL certificate check: how close the certificate is to expiring
How to build an alert chain
An alert reaching nobody, or reaching everybody at once so nobody takes ownership, is where monitoring most often fails in practice. A staged escalation reduces that risk.
- Initial detection: the automated check confirms the failure over 2-3 consecutive attempts, so a single network blip is not mistaken for an outage
- 0-5 minutes: an instant notification to the person on call, in-app or by email
- 5-15 minutes: no response triggers SMS or a phone call, and a second person is notified
- After 15 minutes: a manager steps in, the status page gets updated
What happens during an outage?
The first job when an outage is spotted is not fixing it but understanding its scope: is the whole site down or just one part, how many users are affected, when did it start. Acting without that information risks fixing the wrong thing while missing the actual cause.
A public status page earns its keep at this point; it lets support point every customer to one live page instead of answering each one individually. The page needs updating until the outage ends, and closing once it is resolved.
Why the post-incident review should never be skipped
Once an outage is resolved, a short review gets written: what happened, when it was noticed, how long it took to fix, what changes to stop it happening again. The document exists to prevent a repeat, not to assign blame.
If a spa chain's booking system goes down twice in a row for the same reason, the problem is not technical, it is procedural; whatever fix the first review called for was never actually applied. A second outage for the same cause deserves to be taken more seriously than the first, not less.
Common mistakes
Uptime monitoring can turn into a tool that gets set up once and then forgotten; that happens almost as often as the outages it is meant to catch.
- Monitoring only the homepage while checkout or login goes unwatched
- Sending alerts to one person only, so nobody notices while they are away
- Checking too infrequently, say every thirty minutes, missing short outages entirely
- Moving straight to the next crisis without a post-incident review
Uptime monitoring does not prevent an outage; it makes sure it is noticed before a customer does, and handled in an orderly way. A properly built alert chain and the habit of a short post-incident review shorten how long the next one lasts. A discovery call with rabbitclip is a good place to review your current monitoring setup.
FAQ
Can uptime monitoring be done with free tools?
Yes, a basic ping or HTTP check is covered by many free tiers. Synthetic monitoring and more frequent checks usually sit behind a paid tier.
How often should checks run?
One to five minutes is common for critical pages. More frequent checks catch problems sooner but add load to the server too.
Does every site need a status page?
It is worth having for sites with heavy customer interaction and for e-commerce. A low-traffic brochure site can do without one.
Is a post-incident review about assigning blame?
No. The point is preventing a repeat; the review looks at the process and the system, not at a person.
