Alert Fatigue: How to Tune Uptime Alerts That Matter

Alert fatigue is what happens when a monitoring system cries wolf often enough that people stop listening. The alerts keep coming, the channel gets muted, and the one alert that matters is read hours late. The fix is not fewer monitors; it is alerts that fire only when a human needs to act. This guide covers the specific settings that cut noise without hiding real outages, a review routine to keep it that way, and a tuning table you can apply today.

The rule: every alert should demand an action

Before touching settings, agree on one test. For every notification, ask: did someone need to do something because of this? If the answer is "no, it fixed itself" or "no, we knew already", that alert is noise, and noise trains people to ignore the channel. The goal of tuning is to move as many alerts as possible into one of two buckets:

• Act now: the site is down or broken for users and stays that way. This should interrupt someone.
• Look later: something is degrading or flapping, but not urgently. This belongs on a dashboard or a daily review, not in a push notification.

Most noise comes from things in the second bucket being delivered like the first.

1. Set a fail threshold instead of alerting on a single failure

Networks drop packets, upstream resolvers time out, a deploy restarts a process for two seconds. A single failed check is often not an outage. The fail threshold is the number of consecutive failed checks required before an alert fires. Raising it from 1 to 2 or 3 filters out one-off blips while delaying real alerts only slightly.

Worked example with a 1-minute check interval:

• Threshold 1: you hear about every blip within about a minute, including the ones that are gone by the time you open your laptop.
• Threshold 3: a real outage alerts after roughly three minutes; a 30-second hiccup never alerts at all.

The longer your interval, the lower the threshold should be, because each extra check costs more delay. With a 5-minute interval, a threshold of 2 already means about ten minutes. Our article on choosing a monitoring interval covers this trade-off in more depth.

2. Space out repeat notifications during long outages

Once you know the site is down, a message every minute adds stress, not information. The notification interval controls how often a reminder is re-sent while the outage continues. For a team that is already working the incident, 30–60 minutes is usually right; for an unattended overnight outage, a shorter reminder helps make sure someone eventually wakes up. Plan minimums apply: 60 minutes on Starter, 30 on Plus and 5 on Professional.

The recovery notification is sent separately when the site comes back after an alert, so a long reminder interval does not delay the "it's fixed" message.

3. Use maintenance windows for planned work

Deploys, database migrations, server reboots and backup jobs are predictable, and every alert they cause is pure noise. A maintenance window suppresses checks and alerts during a scheduled period. Windows can be one-off or recurring daily, weekly or monthly, and can cross midnight (for example 23:30–00:30). For ad-hoc work, use quick pause instead. The full playbook is in maintenance windows: pause monitoring without false alarms.

4. Detect flapping instead of paging on it

A site that fails one check, recovers, fails another twenty minutes later and recovers again is a real problem (an overloaded worker pool, a flaky upstream, a memory leak), but it is rarely an emergency at the moment of each blip. Paging on every flap produces exactly the alert pattern that teaches people to ignore alerts.

Uptime Monitor's unstable detection handles this case separately: it flags a site that fails briefly a set number of times within a window of minutes, even though no single failure crossed the alert threshold, and shows it as a badge on the dashboard. You keep the fail threshold high enough to stay quiet, and still see that something is wrong. Treat the badge as a "look later" item and investigate during working hours. See detecting flapping websites for how to diagnose the usual causes.

5. Make "slow" alerts deliberate

Response-time alerts are the most common source of noise, because latency naturally varies. Two settings work together: the response-time threshold in milliseconds and the number of consecutive slow checks required (in Uptime Monitor, the same count as the site's fail threshold). A single slow response is normal; five slow checks in a row is a trend. Set the threshold well above your typical response time (judge it by the P95 of your check history rather than the average) and require several consecutive slow checks before alerting.

6. Route by severity

Not everything should reach the same place. A useful split:

How to build this with Uptime Monitor: every alert goes to all channels you have enabled, so choose channels with that in mind. For escalation, set escalation by duration on important sites: with the first alert or reminder sent after the site has been down for N minutes, a POST also goes to a separate escalation webhook, which can feed whatever tool notifies the next person. For finer routing, point the generic webhook at a small relay that reads notification.severity and event and forwards accordingly; the article on webhook alerts includes a working example.

7. Let automation handle the boring fixes

If the answer to a recurring alert is always "restart PHP-FPM" or "clear the cache", a human is the wrong responder. Automated actions run an SSH command on your server once downtime reaches a threshold, with a configurable number of attempts and a retry interval, and can be limited to specific failure causes such as server_5xx or timeout. You still get the alert and the recovery message, but you are reading about a fix rather than performing one. Keep automating only the fixes that are safe to repeat; see automating server recovery with SSH actions.

8. Review alerts every month

Tuning is not a one-time job; sites, traffic and infrastructure change. Once a month, spend twenty minutes on this routine:

1. List every alert from the past month (the dashboard timeline and the CSV export make this quick).
2. Mark each one: actionable (someone did something), self-resolved, or expected (planned work, known issue).
3. For each self-resolved alert, raise the fail threshold or rely on unstable detection for that site.
4. For each expected alert, add or fix a maintenance window.
5. For each actionable alert that repeats, ask whether an automated action or a real fix would stop it.
6. Check the opposite failure: was there any outage users noticed that did not alert? If so, add a keyword check or lower a threshold.

Write down what you changed. Next month you can see whether it helped.

Tuning table

Key takeaways

• An alert that does not lead to an action is a cost, not a safety net.
• Use a fail threshold of 2–3 so blips do not page anyone.
• Space reminders with the notification interval; recovery messages still arrive immediately.
• Put planned work in maintenance windows and flapping on the dashboard.
• Route by severity and escalate only when an outage persists.
• Review last month's alerts monthly and change one setting per finding.

Every setting in this guide (fail threshold, notification interval, maintenance windows, unstable detection, response-time alerts, escalation and automated actions) is a per-site option in Uptime Monitor. Start on the free plan to tune one site, and see the pricing page if you need shorter intervals or faster reminders.