Testing your routing

Routing mistakes are cheap to catch before real alerts flow and expensive after. Firefight gives you dry-run tools in Settings → Alert Routing and a matching tool for connected AI agents. Dry runs are pure evaluation. No incident is created, no alert is stored, and no message is sent.

Test a single rule

Each rule row in Settings → Alert Routing has a test button. Firefight builds a sample alert from the rule’s own conditions, for example a service is one of checkout condition produces a sample with service set to checkout, and runs it through the full first-match evaluation.

The test runs against all rules in order, not just the one you clicked, and every rule row shows how it went: ✓ fires on the rule that won, ✗ no match on the rules the sample did not match, and skipped (disabled) on rules that are switched off. If the sample is captured by an earlier rule, the row you tested warns that a sample for this rule is captured by that rule first. A shadowed rule like this is the most common routing bug.

Rules with a matches regex condition cannot generate their own sample, because a pattern does not imply a concrete value. Test those with a custom alert instead.

Test a custom alert

The Test custom alert button opens a dialog where you enter the fields a real alert would carry as key and value pairs, such as service, title, or severity_raw. Run test evaluates them and shows:

Which rule matched, by its position in the list (Matched rule 2), or No match.
The winning action, such as Create incident or Notify only.
Who would be notified and who would be invited, resolved against your catalog and members the same way a real alert resolves them.
Warnings for anything that would not resolve, such as a team with no channel set.

When testing a source’s own routing, the evaluation uses that source’s rules with the workspace default as fallback, exactly like real ingest.

Send a test message

When a custom test matches a rule with a notify target, the result offers Send test message. This is the one testing action with a real side effect. It posts a single message labeled Routing test to the resolved target so you can confirm the destination is right and Firefight can post there. It still creates no alert and no incident.

Dry runs from a connected AI agent

POST /api/v1/routing/evaluate does the same evaluation over the REST API, and agents connected over MCP get an evaluate_routing tool for it. The agent passes hypothetical alert fields and optionally an alert source name, and gets back whether a rule matched, the matched rule’s position, the outcome with notify and invite targets resolved to names, the enriched field context, and a per-condition trace showing exactly why each rule did or did not match.

This lets you ask an agent questions like “what would happen if the checkout service fired a critical alert right now” and get a grounded answer from your live rules. The tool is read-only and changes nothing.

A pre-launch checklist

Run each rule’s per-rule test and fix any shadowing warnings.
Run custom tests for your most important services and confirm the matched rule, severity, and targets.
Use Send test message once per notify target to verify delivery.
Send one real request from your monitoring tool and check it appears on the Alerts page with the routing state you expect.

Related pages: Routing rules, How alerts work.