Monitoring and alerting: knowing before your customers do

There is a particular sinking feeling that comes from a customer message that begins, your website seems to be down. They found out before you did. However long it had been broken, every minute was costing you sales and a little trust, and you were completely in the dark.

Monitoring exists to make sure that conversation never happens. Done well, it means you hear about a problem from a quiet alert on your phone, not from a frustrated customer, and often you have fixed it before anyone else even notices.

The worst way to learn you are down#

Relying on customers to report outages is a strategy by default, and a poor one. By the time someone bothers to tell you, plenty of others have simply left and gone to a competitor without saying a word. Silence is not the same as everything being fine.

The fix is to have something watching your site continuously from the outside, checking that it is up, responsive and behaving, so the first to know is always you.

What to monitor#

Monitoring is not a single switch. It is a small set of things worth watching, each answering a different question about the health of your site.

Uptime#

The most basic check is whether your site responds at all. A monitoring service requests a page at regular intervals from one or more locations and records whether it loads. Checking from more than one place matters, because a site that is up for you in the office might be unreachable for visitors elsewhere, and a single vantage point can lie.

Performance#

A site can be technically up and still be failing if it has slowed to a crawl. Tracking response times alongside uptime catches the gradual decline that precedes a full outage, and it shows you when a change quietly made things worse. Google's Core Web Vitals give a sensible vocabulary for the speeds that affect real users, and the MDN performance documentation explains how the underlying measurements are taken.

Certificates#

An expired security certificate breaks a site as effectively as a crashed server, throwing alarming warnings in the browser and turning visitors away at the door. It is also entirely avoidable, because certificates have a known expiry date. Monitoring that date and warning you well in advance prevents an embarrassing, self inflicted outage, and the MDN guide to transport layer security is a clear reference for why these certificates matter in the first place.

Alerts that reach a human#

Collecting data is pointless if nobody acts on it. The whole value of monitoring is the alert, and an alert is only useful if it actually reaches a person who can do something about it.

That means thinking about the channel and the timing. An email is fine for minor warnings, but a site that is fully down warrants something more insistent, a text message or a push notification that cuts through. It also means deciding who is on the receiving end and what they are expected to do, so the alert leads to action rather than landing in an unread inbox. Treating outages as events to be managed, in the spirit of the National Cyber Security Centre's incident management guidance, turns a fire drill into a routine.

Our own monitoring keeps watch around the clock and routes alerts to the right place, so a problem at three in the morning is not waiting politely until you open your laptop.

Avoiding alert fatigue#

There is a failure mode that catches people who take monitoring seriously, and it is the opposite of indifference. Set up too many alerts, or alerts that fire on every trivial blip, and they quickly become background noise. When everything is urgent, nothing is, and the one alert that genuinely matters gets ignored along with the rest.

The cure is restraint. Alert on the things that truly need a human, set sensible thresholds so a one second wobble does not wake anyone, and group related warnings so a single incident does not generate fifty separate pings. A short delay before flagging, to confirm a blip is not just a passing hiccup, removes a surprising amount of the noise. Keeping logs and signals proportionate, as the NCSC suggests in its introduction to logging for security, keeps the useful information from drowning.

Turning data into fixes#

Monitoring that only ever tells you the present moment is a smoke alarm. Useful monitoring also accumulates history, and that history is where the real value hides.

Patterns in the data point straight at root causes. A slowdown every day at the same hour suggests a scheduled job competing for resources. A creeping rise in response time over weeks hints at a database that needs attention before it fails. Watching how real visitors experience your site over time, an approach the web.dev guidance on measuring performance describes well, turns raw numbers into decisions. When a fix is beyond your comfort zone, our support team can read the same signals and act on them with you.

Good monitoring changes your relationship with your website. Instead of nervously hoping nothing breaks, you know that if something does, you will hear about it first, understand why, and put it right before it costs you a single customer. That quiet confidence is the whole point.