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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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.
Ordering matters
Section titled “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.
Rules that create incidents interact with the grouping window, which is configured on the same page. See Grouping & deduplication.