Skip to content

Urgent alerts need a concrete action

A fictional case separates duplicate error alerts from warnings. Fewer interruptions alone do not demonstrate greater reliability.

Lukas Schneider2 min read
Red signal beacon beside a card with a handshake, check marks and a round badge.

An urgent notification should interrupt because a useful action is needed now. If all warnings have the same priority, the on-call person must still do the real classification. Google's SRE book describes how frequent interruptions can lead people to skim or ignore relevant alerts too.

10 messages are not 10 incidents

In a constructed case, 4 instances report the same project-list failure. There are also 6 CPU warnings that need no immediate intervention at that particular moment. The calculation 4 + 6 = 10 counts messages, not independent incidents. The team therefore designs this distribution:

Signal

Assessment in the example

Planned notification route

4 messages about the same portal problem

Shared incident context; affected instances remain visible.

1 grouped urgent notification.

6 CPU warnings

No immediate intervention currently required.

Visible work queue without an urgent interruption.

This distribution is an editorial example, not a measured operating result. The CPU warnings remain under observation. Their investigation simply follows a different notification route.

Fewer interruptions need preserved context

Alertmanager supports grouping and routing to configured recipients. Similar alerts become a shared notification, while the affected instances must remain identifiable. A shared name alone is insufficient when different regions or owners need independent treatment.

Fewer urgent messages demonstrate neither a lower error rate nor faster recovery. Hiding warnings or losing a notification also produces fewer messages for the on-call person. Quality must therefore also be checked against missed problems and a functioning notification path.

When an early resource signal is urgent

The recommendation does not mean always waiting for visible user failures. Prometheus names capacity constraints as a reason for human intervention before an outage occurs. An imminent critical storage shortage or missing required redundancy, for example, can make timely action urgent.

The assessment changes when delay makes substantial harm likely and the team being contacted can act effectively now. Then an early resource signal belongs on the urgent route too. What matters is the concrete response expected and whether it can happen in time; the category CPU, application or infrastructure alone does not decide that.

Sources

Written by

  • Lukas SchneiderTechnical EditorLukas Schneider writes about cloud technologies and running applications at ASES. His articles range from choosing infrastructure to maintenance and backups to monitoring live systems.

Follow ASES

Read more

All articles

Cloud & Operations with ASES

Hosting, deployment, maintenance and support