Which Website Alerts Actually Matter

Every monitoring tool ships with alerting switched on by default, and most businesses quietly turn half of it off within the first month. Not because the alerts were wrong — usually every single one fired for something that genuinely happened — but because there were too many of them, they arrived at the wrong time, and after the fifth 3am message about a CPU blip that resolved itself on its own, the whole channel got muted. That's the real failure mode in most website monitoring setups: not that nothing gets caught, but that everything does, at the same volume, until nobody is reading it anymore.

Alert design is a separate skill from monitoring. Monitoring is collecting the data — response times, error rates, disk usage, certificate dates, job logs. Alert design is deciding which of those numbers, crossing which line, is worth interrupting a person's day for. Get that wrong and you end up with one of two useless setups: a channel so noisy it gets ignored, or a channel so quiet it misses the one thing that genuinely needed a human within the hour.

Two categories, and only one should interrupt anyone

Most things a monitoring system notices fall into one of two buckets: things that need a person to act now, and things a person should know about eventually. Collapsing these into a single stream — one inbox, one chat channel, one set of push notifications, all carrying the same urgency — is the most common mistake in how businesses set up alerting. It isn't usually a tooling failure; most tools support separating urgent alerts from routine ones. It's a decision nobody made on purpose.

What genuinely warrants waking someone up

A short list, and it's short on purpose:

The site is down. Not slow, not degraded — unreachable, or returning errors on every request. This is unambiguous and time-sensitive: every minute it's down is a minute nobody can buy from you, read what you've published, or reach you.

Checkout, or another critical form, is failing even though the rest of the site loads fine. This is arguably worse than a full outage, because the site looks healthy to you and to search engines while it quietly rejects every customer trying to pay or enquire. A check that only confirms the homepage returns a normal response will miss this completely — it's a different kind of check, aimed at a different kind of failure.

A TLS certificate is approaching expiry. This one is fully predictable and entirely preventable, which is exactly why it's one of the more embarrassing ways for a site to go down. Free certificates from services such as Let's Encrypt are commonly issued for a 90-day validity window (Let's Encrypt FAQ), renewed automatically by most hosting setups — but "automatically" is doing a lot of work in that sentence, and automated renewal jobs do fail silently. An alert that fires with real runway before expiry, weeks rather than hours, gives someone time to fix a broken renewal before a browser starts warning every visitor away.

Disk space is running out. Not "trending upward" — actually close to full. A full disk doesn't just slow a site down; depending on what fills it, it can stop a database from writing, stop backups from completing, and stop logs from recording the very information you'd need to diagnose the problem. It tends to take several separate things down at once.

A backup job failed. This one deserves its own explanation, because it's the least intuitive item on this list and, quietly, the most consequential.

Why a failed backup job outranks a CPU spike

A CPU spike, on its own, usually isn't an emergency. Servers are built to handle load variation; a spike that resolves within minutes is often just traffic, a scheduled task, or a search engine crawler having a busy afternoon. It's worth recording. It's rarely worth anyone's immediate attention, and treating every spike as urgent is exactly the kind of thing that trains a team to stop trusting the alert channel altogether.

A failed backup job carries a different kind of risk, and the difference is about what happens next, not what happened just now. Nothing about the site breaks the moment a backup fails — that's precisely the danger. The failure is invisible until the day something else goes wrong and you reach for a backup that, it turns out, quietly hasn't existed in usable form for however long the job has been silently failing. A CPU spike is a symptom you can see immediately. A failed backup is a gap you only discover at the worst possible moment, because by definition nobody was watching for it until it was needed.

That asymmetry — visible-now-but-low-stakes against invisible-now-but-costly-later — is the real test for whether something belongs on the urgent list. It isn't about how alarming an event sounds in a log file. A spike of "500" server errors looks dramatic and is very often nothing; a backup job quietly reporting success without producing a file that would actually restore sounds administrative, and can be the difference between an afternoon's inconvenience and losing weeks of orders, content, or customer records.

What belongs in a digest instead of a page

Most of what a monitoring stack notices deserves visibility, not urgency: a handful of broken links turning up as 404s, a plugin or package update becoming available, a page that loaded a little slower than usual, a non-critical warning buried in a log file, a brief response-time blip that resolved before anyone could have acted on it anyway. Bundling these into a daily or weekly summary keeps them visible — someone should still look — without treating every one of them as an event worth interrupting a day for.

The test is simple: if there's nothing a person can usefully do about it in the next hour, it shouldn't arrive as if there were.

Setting thresholds around business impact, not server curiosities

A lot of default monitoring configuration alerts on things because they're easy to measure, not because they matter. CPU percentage, memory usage, and raw response time are simple numbers to set a threshold on, which is why they're what ships out of the box. But a server running hot while serving every request correctly and quickly isn't a problem. A server running comfortably while failing to process payments is a serious one. The number that's easiest to graph is rarely the number that reflects what a business actually loses when it's crossed.

The more useful exercise is to work backwards from consequence: what would genuinely cost the business money, trust, or data if it went unnoticed for an hour? Then set the alert on that outcome directly — checkout completions dropping to zero, a payment webhook failing repeatedly, a backup job returning a failure status — rather than on a proxy metric that might or might not correlate with it.

An honest limit

None of this prevents every failure. Alerting tells you something is wrong; it doesn't fix it, and a well-designed alert nobody is available to act on is still just noise with better timing. The value of getting the design right is narrower and more achievable than that: it means whoever is available spends their attention on the handful of things that genuinely need it, instead of learning to tune the whole channel out.

Where this fits into ongoing care

Deciding what should page someone immediately versus what can wait for a weekly summary is ongoing work — thresholds that made sense when a site launched can stop making sense as it grows, and someone has to actually read the digest, not just receive it. That kind of attention is part of what a retainer like JagaWeb Care (RM450/month) is meant to cover; Care + Changes (RM1,500/month) adds a monthly allowance for the changes an alert often turns up next — a renewal that needs configuring properly, a threshold that needs adjusting for a site that's grown. Neither is a promise that nothing will ever go wrong; it's a way of having someone watching for the alerts that do.