---
title: "Routing rules"
description: "Conditions, outcomes, severity, and notification targets that decide what each incoming alert becomes."
canonical: https://firefight.app/docs/alerts/routing-rules/
---

# Routing rules

Routing rules decide what happens to every alert Firefight receives. Each rule pairs a set of conditions with an outcome. Rules run in order, top to bottom, and the first rule whose conditions all match wins. Nothing after it is evaluated.

## Where rules live

**Settings → Alert Routing** holds the workspace default routing, the fallback for every source. Each alert source can also carry its own rules, reachable from the **Routing** link on the source row in **Settings → Alert Sources**. At ingest, a source's own routing wins when it exists and is enabled, otherwise the workspace default applies.

From the routing page you can add rules, edit them, reorder them with the up and down arrows, toggle individual rules on and off, and toggle the whole policy. Disabled rules are skipped during evaluation.

If no rule matches, the alert is stored as unmatched. It shows up in **Settings → Alerts** with an unmatched routing state, and nothing is created or sent.

## Conditions

A condition names an alert field, an operator, and usually a value. A rule matches only when all of its conditions match. A rule with no conditions always matches, which makes it a natural catch-all at the bottom of the list.

| Operator | Matches when | Value |
|---|---|---|
| is one of | The field equals any value in the list | A list of values |
| contains | The field contains the value as a substring | A single value |
| starts with | The field begins with the value | A single value |
| matches regex | The field matches the regular expression | A regex pattern |
| is empty | The field is missing or blank | None |

Invalid regex patterns are rejected when you save the rule.

Conditions match against the alert's normalized fields, such as `service`, `title`, `severity_raw`, `team`, `environment`, and for Northflank `event`. Two extra fields are always available, `source` carries the alert source's name and `provider` carries its type (`generic` or `northflank`).

When the alert's `service`, `team`, `environment`, or `functionality` field names an entry in your catalog, Firefight enriches the alert before evaluation. Related entries one hop away are merged in, so an alert carrying only `service: checkout` also gets `team` filled from the service's owning team. The entry's attributes become dotted fields like `service.tier`, so a condition such as `service.tier` `is one of` `Critical` routes by catalog metadata the alert itself never sent. When you write an `is one of` condition on a catalog field, the value picker offers your catalog entries directly.

## Outcomes

Every rule ends in one of four actions.

| Action | What it does |
|---|---|
| Create incident | Declares an incident named after the alert, with the alert's description as the summary. Grouping applies first, so a matching open alert group attaches instead of creating a duplicate. |
| Attach to open incident | Attaches the alert to the incident of an open alert group with matching grouping fields. If no such incident is open, nothing is created. |
| Notify only | Posts an alert message to a target without creating an incident. |
| Drop | Stores the alert and does nothing else. Useful for known noise. |

## Setting severity

For the two incident actions you choose the severity of the incident the rule creates. Pick a specific severity, or pick **Severity from source map** to use the source's severity mapping on the alert's raw severity value, falling back to the workspace default severity when unmapped.

## Notify targets

A **Notify only** rule sends its message to one of three targets.

| Target | Where the message goes |
|---|---|
| Channel | A Slack channel you pick |
| Person (DM) | A direct message to a workspace member |
| Owning team's channel | Resolved from the catalog at fire time. The service's own channel wins when set, otherwise the owning team's channel |

The owning team target follows your catalog, so reorganizing ownership there redirects alerts without touching any rule.

## Invite targets

Rules with an incident action can invite people into the incident channel. You can toggle **Owning team**, which resolves the alert's service to its owning team in the catalog and invites the team's members and manager, and you can add specific people by name. Resolution happens at fire time, and anything that cannot be resolved is noted on the incident rather than blocking its creation.

:::note
Owning-team resolution depends on your catalog. The service entry needs a relationship to a team entry, and the team entry needs its members, manager, or channel attributes set. When something is missing, the incident is still created and the gap is recorded as a note.
:::

## Ordering matters

Because the first match wins, put your most specific rules at the top and broad catch-alls at the bottom. A wide rule placed early can shadow everything under it. The per-rule test in **Settings → Alert Routing** warns you when a rule's own sample alert is captured by an earlier rule. See [Testing your routing](https://firefight.app/docs/alerts/testing-routing.md).

Rules that create incidents interact with the grouping window, which is configured on the same page. See [Grouping & deduplication](https://firefight.app/docs/alerts/grouping-and-deduplication.md).