How to set up uptime alerts without alert fatigue

Monitoring is only useful if the alerts are trusted. If your phone buzzes for every blip, you will soon ignore it, and the one alert that matters will be missed. If alerts are too rare, customers tell you about outages before your own tools do. This guide covers how to find the balance.

Start with what matters to users

Do not begin with a list of servers. Begin with what your visitors need to do: load the home page, sign in, search, pay. Each of those journeys is worth watching, because a site can respond to a simple request while a key feature is broken. A page that returns a normal response but shows an error message is a very common failure, so check for a specific word on the page as well as the status code. Our monitor supports keyword and port checks for this reason.

How often to check

Frequency is a trade-off. Checking every minute detects a problem within about a minute, but small, brief problems will trigger more alerts. Checking every five minutes is calmer and is plenty for most small sites. A rough guide:

• Business-critical services (payments, sign-in): every minute.
• Normal websites and shops: every one to five minutes.
• Blogs, brochure sites, internal tools: five to fifteen minutes.

Wait for confirmation before alerting

The biggest single cause of false alarms is alerting on one failed check. The internet is not perfectly reliable: a lost packet, a busy moment or a short network blip can fail a single request without any real problem. A better rule is to alert only after two or three consecutive failures, or when several locations agree. That adds a few minutes of delay and removes most of the noise. It is the same principle we use: we count a site as down only after repeated failed checks, as described in how our checks work.

Check from more than one place

If the only thing watching your site sits next to it in the same data centre, it will happily report that everything is fine while visitors elsewhere cannot get through. Checking from outside, and from a few regions, shows what real people see. It also helps you tell a partial problem, such as one region or one provider, from a total outage. See why a site can be down for some people and not others.

Separate urgent from informational

Not every event deserves the same noise. Sort alerts into levels:

• Wake someone up: the site is down or checkout is failing.
• Look at it today: responses are slow, a certificate expires in two weeks, a domain renews soon.
• Just record it: a short blip that recovered by itself.

Routing the second and third groups to email rather than a phone alarm keeps the urgent channel meaningful. Certificate and domain expiry in particular should alert well in advance, since they are entirely preventable. See domain name expiry and SSL certificate errors.

Tell the right people, in the right place

Decide in advance who receives each alert and what they should do first. One named person on call is better than a group that each assumes someone else will respond. Send alerts to the place people already look, such as email, Telegram, Slack or Discord, and include in the message what failed, since when, and a link to the status or runbook.

Alert on recovery too

A “back up” message tells the team they can stop investigating and gives you the length of the outage for your records. It also confirms that the problem was real. Without it, a quiet channel is ambiguous.

Review regularly

• Once a month, look at which alerts fired and which needed action. Any alert that never needs action should be loosened or removed.
• After each real incident, ask whether you heard about it quickly enough, and whether an earlier warning, such as slow responses, was missed.
• Keep an eye on the trend of your uptime. Our guide to uptime percentages shows what each figure means in minutes of real downtime.

Good alerting is quiet most of the time, specific when it speaks, and impossible to ignore when it matters. When something does go wrong, tell your own users promptly, using the approach in how to write an outage update.

Related guides

• How to monitor your own website: what to check and how often
• Uptime percentages explained: what 99.9% really means
• How to write an outage update that people will trust

Last updated 2 November 2026. Written by the siteupdown.com team. Spotted a mistake?

← All help guides