Skip to main content
Settings → Alert rules decides which alerts are delivered to your Slack webhook. The rules are yours alone. Two people in the same organisation can reasonably want different interruptions, and the webhook an alert arrives on belongs to each of them separately — so routing is per person, not per organisation.

​
Doing nothing keeps what you had

A member who never opens this pane receives exactly what they received before it existed: every new-finding alert, at every severity. Nothing is muted by the feature arriving, and the pane says so on its face.
That is why “no rule” and “muted” are stored as different things. An absent row means never chose, and the default applies. enabled = false means chose silence, and it is honoured.

​
What can be routed

The threshold counts only what that scan introduced, never the findings already open. Applying it to the open-findings rollup would fire “new HIGH findings” at someone whose HIGH findings have all been there for months, which is how people learn to ignore alerts. The scan-failure alert exists because a repository whose scans have been failing for a fortnight looks exactly like a repository with no findings. The message says so directly: this repository’s findings are unchanged from its last successful scan, not confirmed clean.

​
What cannot be routed, and why

The Alerts feed in the app renders more kinds than this pane offers. The missing ones have no moment on the server where a message could go out:
These are named rather than shown as switches. A switch wired to nothing is indistinguishable from one you muted — you would flip it, receive nothing, and conclude the rule worked.
They all still appear in the Alerts feed when you look; the feed reads stored history, which is a lower bar than delivering a message.

​
Delivery

Alerts go to the Slack webhook configured on your Integrations pane. Without one, these rules decide nothing — and the pane says that too, rather than letting you tune settings that cannot fire.