Reducing alert noise

When a database dies it takes everything behind it with it. Most monitoring tools then send one alert per broken thing — forty pages, thirty-nine of them noise, and the one that tells you what actually broke buried somewhere in the middle. UptimeGlobe does two things about that. One needs no setup at all.

Events

Incidents that open within about two minutes of each other are tied together into a single event. This is automatic — there is nothing to configure. You will see an Event · N badge on the incident list, and opening any one of them shows every monitor caught up in it, ordered by which failed first.

That ordering is the point. A count tells you how bad it is; the order tells you where to look. The monitor at the top of the list is usually the closest thing to a root cause — the database that went first, before the API and the checkout page that depend on it.

This is on for every account and every plan. There is nothing to switch on and nothing to declare.

Note

A single monitor flapping up and down is not called an event, even though its incidents cluster in time. An event needs at least two different monitors.

Dependencies

Grouping makes an outage readable after the fact. It does not stop your phone ringing forty times at 3am. For that, tell us what depends on what.

Open any monitor, and under Depends on pick the thing it needs. Your checkout API depends on your database; your storefront depends on the API. When the database is already down and the API fails, we do not alert you about the API. You get paged about the database.

Nothing is hidden. The API incident still opens. It appears on your dashboard, in the API, in exports, and on your status page exactly as it always would, tagged No alert sent with the reason. Only the notification is held. That is the difference between quieting an alert and losing an outage, and we are careful about which one this is.

It works for every monitor type, not just websites — a nightly import heartbeat can depend on the database it reads from.

When we alert anyway

A feature that withholds alerts is only worth having if you can predict exactly when it will not. We send the alert — ignoring the dependency entirely — in all of these cases:

Case	What it means
It broke first	The monitor was already failing before its dependency was, so it broke on its own.
Paused or deleted	A dependency nobody is checking cannot tell us anything.
Running late	The dependency has fallen behind its own schedule, so its “healthy” is out of date.
Anything unexpected	If we cannot work out the answer, you get the alert.

Every one of those errs toward waking you up. The worst outcome for a noise-reduction feature is silence, so each rule is written to fail in the noisy direction.

One to watch

If the dependency is checked less often than the monitor that depends on it, it may not have noticed the outage yet, and you will get both alerts. The edit form warns you when you pick a slower dependency. It is a legitimate setup — a cheap daily database check under a one-minute API check — it just means suppression will sometimes miss.

Reference

Question	Answer
Does this cost anything?	No. Both are on every plan, including free.
Do suppressed incidents show on my status page?	Yes. Suppression only holds the notification — the incident is public exactly as it would otherwise be.
Do I get a “resolved” for a suppressed incident?	No. If you were never told it broke, telling you it recovered is just confusing.
Can I chain dependencies?	Yes — storefront to API to database. Up to three levels. Loops are rejected when you save.
What if the dependency is in a maintenance window?	Treated as down, so its dependants stay quiet too. A monitor in maintenance is expected to be unavailable.
Why did I not get paged?	Open the incident. The Alert row says whether it was sent, held by a dependency (and which one), or held by a maintenance window.