Knowing Your Site Is Down Before Your Customers Tell You

“Up” is not the right question

A server can respond happily while the checkout is broken, the login fails or the database has run out of space. Basic uptime monitoring reports green throughout.

Monitor the journeys that matter: can someone load the homepage, submit the enquiry form, log in, complete a purchase? Those checks catch the failures customers actually experience.

What to monitor

1. Key user journeys, end to end, every few minutes
2. Error rates, because a rise usually precedes a visible failure
3. Certificate expiry, at least a fortnight ahead
4. Disk space and database connections, which fail predictably and catastrophically
5. Backup success, since a silent backup failure is discovered at the worst time
6. Integration health — is data still flowing between systems?

Alert a person, on a channel they read

An alert to a shared inbox is not an alert. Send it to a named person's phone, and make sure someone else receives it when they are on holiday.

For a small team, a simple rota with an agreed escalation contact is enough. Elaborate on-call arrangements are not necessary and will not be followed.

Alert only on what needs action now

Every non-actionable alert reduces the attention paid to the next one. Within a fortnight of noisy alerting, people stop reading them, and then a real one is missed.

• Page for: site down, checkout failing, data loss risk
• Email for: elevated errors, integration failures, capacity trending up
• Dashboard for: everything else
• Review monthly and delete any alert nobody acted on

Check from outside

Monitoring that runs inside your own infrastructure fails when your infrastructure fails. External checks from more than one location catch outages and regional problems that internal monitoring cannot see.

Also check the things you do not control — payment provider, email service, key APIs — because their outage is your outage as far as customers are concerned.

Frequently asked questions