Every monitoring tool eventually produces an alert that was not real. What decides whether your monitoring survives is how often that happens — because once a team has learned that the alerts are usually noise, they will treat the real one exactly the same way.
From $5 a month · No check quotas · Set up in under a minute
How do you stop monitoring alerts being ignored?
Make every alert mean something. Confirm failures before alerting rather than firing on the first one, watch the specific part of a page that matters rather than the whole thing, filter the elements that change on every load, and alert on state changes rather than on every failed check. Most alert fatigue is a configuration problem wearing a discipline problem's clothes.
Alert fatigue is usually described as a human problem — people should pay more attention. It is almost always a configuration problem. A monitor that fires when nothing is wrong is doing what it was told; the instruction was wrong.
The reason it matters more than most monitoring decisions is that trust is spent once. A team that has ignored forty false alarms will ignore the forty-first, and that one will be real. There is no setting that repairs that afterwards — you have to prevent it.
In rough order of how much noise each one produces.
A single failed check is weak evidence. Packets get dropped, routes flap, a server garbage-collects for two seconds. Tools that page on the first failure convert every transient blip into an incident. Re-checking before alerting removes most of this at the cost of a few seconds of detection time.
If your monitor checks from a single location, a routing problem between that location and your site is indistinguishable from an outage. Tools that confirm from a second location before alerting separate "your site is down" from "one path to your site is down" — and that distinction is most of the false-alarm problem. We re-check before alerting, but from the same location, which is an honest limitation of how we work.
A page contains a cookie banner, a carousel, a live chat widget, a relative timestamp and a view counter. Watching all of it means being alerted every time any of it moves. Watching the one region that matters turns a useless monitor into a precise one.
Without a minimum, a single changed word fires an alert. Most pages change trivially all the time. A threshold lets small edits be recorded without anyone being emailed.
If a site is down for an hour and you check every minute, you do not need sixty alerts. One when it goes down and one when it recovers is the correct number, and anything else trains people to filter the sender.
A certificate expiring in thirty days and a checkout page returning 500 are not the same urgency. When they arrive in the same channel looking identical, the important one gets the attention the unimportant one earned.
Roughly in order of how much noise each removes per minute of effort.
| Fix | Removes | Effort |
|---|---|---|
| Confirm before alerting | Transient network blips | Usually a setting |
| Confirm from a second location | Routing and probe problems | Depends on the tool |
| Watch a region, not the page | Banners, widgets, carousels | A minute per monitor |
| Ignore rules for noisy elements | Counters, clocks, timestamps | A minute per monitor |
| Set a change threshold | Trivial single-word edits | A setting |
| Alert on state change only | Repeat alerts during one outage | Usually default |
| Route by severity | Urgent things lost among routine | Half an hour, once |
Uptime checks are binary. Content watches are where tuning actually matters.
Click the price, the clause, the table — whatever you actually care about — and everything outside it is ignored. This single step removes more false alerts than every other fix combined, because most of a page is not the part you are watching for.
Cookie banners, ad slots, chat widgets, carousels and relative timestamps change on their own schedule and have nothing to do with your content. Blocking them by default is the right behaviour, and patterns can catch counters and clocks that survive it.
Fetching a page twice, seconds apart, and comparing the two reveals everything that differs between two immediate loads. Nothing that changes in two seconds is a real content change, so those elements can become automatic ignore rules before you ever receive a false alert.
If only a price change matters, alerting on lines containing price-related words means the rest of the page can move freely without producing anything. This turns a broad watch into a specific question.
If you are already here, do not tune — restart.
When a channel has become noise, incremental tuning does not work, because nobody is watching closely enough to notice it improving. The faster route is to stop alerting entirely from that channel, fix the three or four monitors producing most of the volume, and reintroduce alerts to a new destination that starts clean.
It is also worth auditing what you monitor at all. A surprising amount of alert fatigue comes from monitors somebody created once for a reason that no longer exists, watching pages nobody owns, firing into a channel nobody reads. Deleting a monitor is a legitimate fix and usually an underused one.
Stop a noisy monitoring setup from being ignored.
It is usually three or four out of however many you have.
Re-checking a failure before it becomes an alert removes most transient noise.
Select the part of the page you actually care about; ignore everything else.
Filter banners, counters and clocks, and require a minimum change before alerting.
Urgent alerts somewhere that interrupts people; routine warnings somewhere that does not.
A monitor whose alerts never produce an action is producing noise, not information.
Typically about 30 minutes from start to finish.
Uptime monitors, watched pages and heartbeats each get their own allowance, so adding a page watch never costs you a monitor. SSL and domain checks ride along with the monitor they belong to and use nothing extra.
| Plan | Monitors | Watched pages | Heartbeats | Fastest interval | Alert channels | Price |
|---|---|---|---|---|---|---|
| Free | 1 | 1 | 1 | Every 30 minutes | 1 email address | $0 |
| Founding Member first 20 only | 25 | 25 | 25 | Every 5 minutes | Email + webhook & chat | $5/mo |
| Basic | 10 | 10 | 10 | Every 10 minutes | Email + webhook & chat | $8/mo |
| Growth | 50 | 50 | 50 | Every 5 minutes | Email + webhook & chat | $19/mo |
| Pro | 100 | 100 | 100 | Every 60 seconds | Email + webhook & chat | $34/mo |
Annual billing is cheaper on every paid tier. The pricing page is the authoritative list.
Every recorded change is compared word by word and kept with a before-and-after image. This is the real output, shown with worked example data.
Price fell from $49 to $39, and an annual discount was added.
The item is available again and the basket button returned.
A new subprocessor was added in another jurisdiction.
The free plan sends to one email address. Every paid plan adds the chat and webhook channels below, with 2 to 10 destinations depending on the plan. However many alerts you receive, the price does not change — nothing here is metered or charged per alert.
There are no voice calls and no SMS. If a phone call at 3am is a hard requirement, say so before you subscribe — we would rather tell you now than refund you later.
Most often alerting on a single failed check, or checking from one location and treating a routing problem as an outage. Both are fixed by confirming a failure before alerting, ideally from a second location.
Any alert that does not produce an action is too many. If people are filtering, muting or skim-reading the channel, the volume is already past the point where the monitoring works.
No. One alert when a monitor changes state to down and one when it recovers is correct. Repeating every check during an outage teaches people to filter the sender, which costs you the next real alert.
Almost always because it is watching the whole page. Cookie banners, carousels, chat widgets, counters and timestamps all change on their own. Selecting the specific region you care about fixes most of it in under a minute.
Significantly, because a genuine outage fails from everywhere and a routing problem fails from one place. Tools that confirm across locations before alerting have the strongest defence against this. We re-check before alerting but from a single location, which is a real limitation.
Stop alerting into it, fix the few monitors generating most of the volume, and reintroduce alerts to a new destination. Incremental tuning does not work once nobody is reading closely enough to notice the improvement.
Rarely. It is usually a configuration problem — monitors that were told to watch too much, alert too eagerly, or report at a severity that does not match what happened. The people are behaving reasonably given what they are receiving.
No. A certificate expiring in thirty days needs a ticket; a checkout returning 500 needs someone now. Routing them identically means the urgent one inherits the attention the routine one deserves.
Last updated August 4, 2026 · Written by Amit Gupta, founder of MonitoringDaddy
Region selection, automatic noise filtering and thresholds on every plan, from $5 a month.