> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pipefort.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Alert rules

> Choose which alerts reach your Slack, and at what severity.

**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

<Note>
  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.
</Note>

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

| Alert                                                                    | Severity threshold            |
| ------------------------------------------------------------------------ | ----------------------------- |
| **New findings** — a scan introduced findings that were not there before | Yes                           |
| **Scan failed** — a scan could not complete                              | No; a failure has no severity |

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:

| Not offered              | Why                                                                                                          |
| ------------------------ | ------------------------------------------------------------------------------------------------------------ |
| Finding resolved         | A scan knows what it introduced, not yet what it cleared — there is no number to send.                       |
| Finding reappeared       | Recorded in the timeline, but the scan path has no delivery step for it yet.                                 |
| Triaged / triage expired | Both happen away from a scan — one is your own click, the other a nightly sweep with nothing wired to Slack. |
| Fix pull request opened  | You are standing in front of the screen that opened it.                                                      |

<Warning>
  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.
</Warning>

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](/webapp/notifications) pane. Without one, these rules decide
nothing — and the pane says that too, rather than letting you tune settings
that cannot fire.