How to Stop Sentry Slack Alerts From Becoming Noise

Cutting Sentry-to-Slack noise without losing real issues means replacing one blanket alert rule with several narrower ones. Route by severity so only fatal and unhandled errors hit an on-call channel, send everything else to a lower-priority triage channel, and filter by team or project so people only see what they own. Sentry gives you the pieces to build this. It does not build it for you, and it does not maintain it as your team grows.

The failure mode is familiar if you've ever muted a channel. One alert rule fires on every new issue, the channel fills with retry-storm 500s and errors from a staging-adjacent project nobody triages, and eventually the team stops reading it at all, including the day something actually breaks. The fix isn't turning alerts off. It's making the rules that decide what reaches Slack do more work than "issue is new."

Start from one rule, not the default catch-all

Most Sentry projects ship with a single alert rule created during setup. It notifies on every new issue and sends everything to one channel. Sentry's own alert configuration docs describe more deliberate building blocks. A when trigger, such as "when an issue is created" or "when an issue escalates," pairs with if filters like "assigned to a specific team" or "at a certain severity." Those fire a then action, a Slack message, an email, a PagerDuty page, or a ticket in Jira or Linear.

The catch-all rule collapses all three of those into one undifferentiated firehose. The fix is building several narrower rules instead of tuning the one you have.

Route by severity so fatal doesn't share a channel with warning

Create a rule filtered to a certain severity that posts only fatal and unhandled errors to an on-call or incidents channel, and a second, broader rule for everything else that posts to a general triage channel nobody's paged for. Sentry's own alert configuration guidance lists filtering "at a certain severity" as one of the standard ways to narrow a rule down. Its Slack integration docs confirm each alert rule targets its own Slack workspace and channel or user, and that the notification carries real actions. An error alert posted to Slack ships with Resolve, Archive, and Assignee buttons right from the message, without switching tools.

That last part matters more than it looks. Resolving noise inside Slack, instead of always tabbing back to Sentry, is most of what makes a lower-priority channel bearable to read.

Split by team or project before splitting by severity

Severity alone still puts a fatal error from an internal admin tool in the same channel as a fatal error in checkout. Sentry's alert docs list "assigned to a specific team" as its own filter, separate from severity, so you can route each team's fatal-and-above issues to that team's own channel by project or by ownership. A platform team that owns five services doesn't need every other team's warnings; a checkout team doesn't need to filter platform noise out of their view by eye every morning.

This is also where the maintenance cost shows up. Every new service is a project that needs its own rule, every reorg is a set of channel names to update, and a rule nobody remembers writing is a rule nobody notices has started misfiring.

A healthcare scheduling team drowned one channel, split it, then got surprised anyway

Emeka Nwosu is a platform engineer at Palmerston Health, which runs scheduling software for outpatient clinics. The team has one Sentry project per clinic-facing service, and for two years, every project fed the same #eng-errors channel with one blanket rule that posted every new issue straight to Slack.

Nadia Brandt (support lead): Someone paged in #eng-errors about appointment reminders failing for East Ridge Clinic. Is that the same thing three other people mentioned this week?

Emeka: Honestly, not sure. That channel's had 40+ posts today and I stopped reading closely around Tuesday. Let me search.

He searches Sentry directly instead of the channel, because the channel itself had stopped being useful as a record. He finds the East Ridge issue, confirms it's a timeout in the SMS provider, and separately confirms two of the "other mentions" Nadia remembered were an unrelated staging error and a warning-level issue that had already auto-resolved.

Emeka: Found it, one real issue affecting East Ridge specifically, fixing now. The other two weren't related, they just got lost in the same feed.

Nothing in that exchange was Sentry's fault. The SMS timeout was caught and logged correctly. What broke down was that a channel carrying 40 daily posts, spanning every clinic and every severity, had stopped functioning as a place anyone could scan for what mattered that hour.

The fix Emeka shipped afterward was the two-layer split from the sections above. Fatal and unhandled errors from any clinic-facing project now route to #eng-oncall, everything else lands in #eng-triage, and a project-ownership rule keeps the billing team's issues out of the scheduling team's channel. For a few months, #eng-oncall carried two or three posts a day, and all of them were worth reading.

Then Palmerston Health signed a fourth clinic chain and stood up a sandbox project to test its intake form against production-like data before rollout. Nobody wrote a routing rule for the new sandbox project specifically, so it inherited the default rule instead, fatal and unhandled straight to #eng-oncall, same as a live clinic. A null-pointer error in the sandbox's appointment-reminder code fired at 2 a.m. a week later, paged the on-call rotation exactly like a production fatal would, and cost twenty minutes before anyone confirmed no real patient reminder had actually failed. The severity rule did exactly what it was configured to do. It had no way to know that "fatal, in this project, right now" meant something different from "fatal, for a paying clinic, right now."

What routing rules can't see

Severity-and-team routing is a real improvement, and it's also a system that degrades the same way most manual configuration does. Palmerston Health's sandbox project is one version of that. A rule inherited by default, not written on purpose, still did exactly what it was told.

• Rules don't know about customers. A severity filter treats a bug hitting an internal sandbox project the same as one hitting your biggest renewal this quarter, because Sentry has no concept of account value to filter on.
• Someone has to keep the rule set current. New projects, new teams, and org changes all mean editing rules by hand. The sandbox project only landed in the fatal-alert rule because nobody remembered to write it one of its own, and a rule set drifts out of date the same way tag taxonomies and label lists do in most manual tracker systems.
• Rules reduce volume; they don't add context. An issue that clears the severity bar still lands in Slack as a stack trace. Whether it's affecting one person or an entire enterprise account is a separate lookup, every time.

That third point is the one that tends to force the next step. Once routing rules are tuned as well as they can be and the channel is still noisy relative to what people need to act on, the missing piece isn't a better filter, it's a fast answer to how much a given issue actually matters once someone is looking at it. That's the layer Modem works on. Modem doesn't change what Sentry sends to Slack or score issues before they post. Modem's Sentry integration lets an agent search issues, read stack traces and sample events, and review the user feedback submitted through Sentry, next to the account and conversation history Modem already holds on the customer behind it, and resolve, assign, or reprioritize the issue from there with your approval. It's a companion to routing rules, not a replacement for them. Severity and team scoping still do the first pass of filtering, and Modem is what someone reaches for once an alert is already in front of them and the real question is who it's costing you. For the related question of matching a specific issue back to the customers it affected, see how to find out which customers hit a Sentry error; the underlying idea of keeping errors linked to the accounts behind them is covered in what a customer context graph is. We build Modem, so weigh that against tuning the routing layer further yourself.

The two-rule minimum

Split your single catch-all rule into two: one filtered to fatal and unhandled errors, posting to an on-call channel, and one for everything else, posting to a lower-priority channel nobody's paged for. That alone stops the failure mode where a real outage looks exactly like the day's hundredth warning.