How to automate Slack alerts from monitoring tools without the noise

Connecting a monitoring tool to Slack takes about two minutes, which is why most organisations have done it four times. The result is a channel receiving alerts from four systems, none of which knows about the others, all of which fire simultaneously during an incident.

What makes the difference is not the connection but the layer between the tools and the people: something that deduplicates, groups, routes by who should act, and suppresses what does not need anybody. That layer is what turns a feed into a signal.

What we'll cover

• Why direct connections fail
• The layer worth building
• Deduplication and grouping
• Building it with CodeWords
• Routing to a person
• Suppression, which needs care
• What the message should contain
• Deciding what deserves a person at all
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why direct connections fail

Each tool sends everything it knows about, with no view of the others.

One incident produces many alerts. A database problem generates alerts from the database monitor, the application error tracker, the synthetic check, and the load balancer — four messages about one thing.

No tool can suppress another's output, so the volume during an incident is exactly when the channel is least readable.

Severity means different things per tool, so a channel receives four incompatible scales presented identically.

Nobody owns the channel. It accumulates integrations because each was a two-minute job, and no one is responsible for what it contains.

The result is predictable: the channel is muted, and the alert that mattered is muted with it.

The layer worth building

Four functions, and each is worth more than the connection.

Deduplication, so one condition produces one message however many tools noticed it.

Grouping, so related alerts arrive together with a summary rather than individually.

Routing, so an alert reaches the person who can act rather than a channel where everybody assumes somebody else will.

Suppression, so known conditions, maintenance windows, and alerts nobody acts on do not consume attention.

The layer can be modest. This does not require a platform — it requires something between the tools and Slack that applies rules you decided deliberately.

Deduplication and grouping

Key on the condition, not the alert. Service, component, and the nature of the problem — not the tool that reported it or the timestamp.

One message per condition, updated as it develops rather than repeated.

Update in a thread. A condition that changes three times becomes one thread instead of three messages, which changes how busy the channel feels more than any filtering.

Group by incident where you can. Eleven alerts within two minutes on related components is one event, and presenting it as one message with the components listed is far more useful.

Report the count. "Eleven related alerts" tells a responder the scale immediately, which individual messages never do.

Collapse flapping. A check oscillating produces a stream, and a single message saying it has flapped eleven times in ten minutes is the useful version.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the monitoring tools, the on-call rota, and Slack can meet in one place where the rules live.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which sources, how alerts should be grouped, and who should be told.
3. Authorize the connections — the monitoring tools, the rota or calendar, and Slack.
4. Describe the exceptions: a flapping alert, a maintenance window, an alert nobody has acted on in months.
5. Run it in parallel with the existing connections for a week and compare the volume.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Routing to a person

A channel message is addressed to nobody, which is why alerts in channels get less response than their urgency deserves.

Route by service ownership to the team, and by rota to the person, for anything needing action now.

Use the actual rota, not a static list, since an alert to somebody not on call is an alert to nobody.

Escalate on no acknowledgement, which requires knowing whether anybody responded — and a Slack message alone cannot tell you that, which is the argument for a paging tool sitting alongside for the urgent tier.

Keep the channel for awareness, with the actionable ones going to people, rather than expecting a channel to do both jobs.

Tell the rest of the team too. An alert going to one person plus a channel note is better than either alone, because it prevents duplicate investigation.

Suppression, which needs care

Maintenance windows, automatically, from whatever holds the schedule.

Known conditions with an expiry, never indefinitely — an alert suppressed forever is an alert deleted, and it should be deleted deliberately if that is the decision.

Dependencies. If a database is down, suppress the eleven services reporting they cannot reach it and say so in the message instead.

Low-value alerts that have never led to action, which is a decision to make with the data rather than by irritation.

Record every suppression and review it, because an unreviewed suppression list quietly becomes the reason nobody found out about something.

Do not suppress by muting the channel, which is what happens by default and is the least selective possible version of all of this.

What the message should contain

What is wrong, in service terms, rather than the monitoring tool's phrasing.

How bad and how many — the count of related alerts and whether it is worsening.

What changed recently. Deployments in the preceding minutes answer a large share of incidents on their own.

Whether it has happened before, with the previous resolution, which is the single most useful line a responder can read.

A link to the relevant dashboard, pre-filtered, rather than to a home page.

What to do, if known — a runbook link, or an honest note that there is not one.

Deciding what deserves a person at all

The uncomfortable question underneath all of this is how many of the current alerts should exist. Most alert volume is inherited: somebody added a threshold during a bad week years ago and nobody has revisited it since.

Count actions, not alerts. For each alert type, how many times in the last quarter did anyone do anything as a result? The answer is frequently zero, and a zero-action alert firing weekly is pure cost.

Separate the tiers explicitly. Something requiring action now, something requiring action today, and something that is only context. Three tiers is enough, and most organisations have one tier pretending to be three.

Alert on symptoms rather than causes where you can. A customer-facing failure is worth waking somebody for; a CPU threshold is a guess about what might eventually cause one.

Delete rather than suppress when the decision is that nobody should see it. Deleting is honest and reviewable; suppressing is the same outcome hidden in a config file.

Make adding an alert require a response. What should the recipient do? If that cannot be answered, it belongs in a dashboard rather than a channel.

Review quarterly against the action count, because the volume grows monotonically otherwise and no single addition ever feels like the problem.

Making it survive

Do not run the alerting on the thing being monitored, which is the classic mistake and guarantees silence at the worst moment.

Make it degrade to pass-through. If the layer fails, alerts should still reach somebody, unfiltered, rather than disappearing.

Alert on the layer itself through a different route, since a broken alerting pipeline looks exactly like a quiet period.

Handle at-least-once delivery from every source, since duplicates are normal.

Report the outcome. Alerts received, deduplicated, routed, and suppressed with the reason — the suppression count is the one people should look at.

Limits worth knowing about

Slack rate limits apply, which matters most during an incident when volume peaks.

Slack is not a paging tool. A message does not wake anybody, and acknowledgement is not tracked — which is why an urgent tier needs something else alongside.

Thread updates are easy to miss for anybody not already in the thread, so a significant change deserves a new message.

Each tool's severity scale is its own, and normalising them across sources is a judgement you have to make explicitly.

Retention is a workspace setting, so the channel is not an incident record however convenient it looks.

What to build first

Deduplication keyed on the condition rather than the alert, so one problem produces one message however many tools noticed it. It is the change that most reduces volume during an incident, which is exactly when the channel is least readable and most needed.

Two habits make the difference. Thread subsequent updates rather than posting again, since that alone halves how busy the channel feels. And review the suppression list monthly, because an unreviewed suppression is how a real problem comes to be filtered out permanently by a rule somebody added during a bad week.

Frequently asked questions

Why does connecting monitoring tools directly to Slack fail?

Because each tool sends everything it knows with no view of the others, so one incident produces four messages from four systems. The channel gets muted, and the alert that mattered is muted with it.

What should the layer between tools and Slack do?

Deduplicate on the condition, group related alerts, route to people rather than channels, and suppress what nobody acts on. The connection is trivial; those four functions are the value.

How do I reduce volume during an incident?

Deduplicate on the condition rather than the alert, group related alerts into one message with a count, and suppress dependent services when their dependency is the actual failure.

Should alerts go to a channel or a person?

Actionable ones to a person, using the actual rota rather than a static list. Channels are for awareness. A channel message is addressed to nobody, which is why it gets less response than its urgency deserves.

Is Slack enough for on-call?

No. It does not wake anybody and it does not track acknowledgement, so an urgent tier needs a paging tool alongside. Slack is a good place for everything below that tier.

When is suppression dangerous?

When it has no expiry and nobody reviews it. An indefinitely suppressed alert is a deleted alert, and an unreviewed list is how a real problem comes to be permanently filtered by a rule added during a bad week.

What is the most useful line in an alert?

Whether this has happened before and what resolved it. It is the thing a responder most wants at an awkward hour and the thing they are least able to look up quickly.

How do I decide which alerts to keep?

Count how many times in the last quarter anyone acted on each alert type. Zero-action alerts firing weekly are pure cost. Then require every new alert to answer what the recipient should do — if it cannot, it belongs in a dashboard.

Should alerts fire on symptoms or causes?

Symptoms where you can. A customer-facing failure is worth interrupting somebody for; a CPU threshold is a guess about what might eventually cause one, and it is the kind of guess that produces most inherited alert volume.

Related reading

• Automating API health checks
• PagerDuty and CodeWords
• Datadog and CodeWords