---
title: "Testing your routing"
description: "Dry-run routing rules against sample alerts from the settings UI or a connected AI agent, without creating anything."
canonical: https://firefight.app/docs/alerts/testing-routing/
---

# 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 result badge on the rule shows whether the sample created an incident, attached, notified, or dropped. Crucially, the test runs against all rules in order, not just the one you clicked. If the sample is captured by an earlier rule, the row warns you that the rule is shadowed, which 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, or that nothing matched.
- 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 clearly labeled message 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

Agents connected to Firefight over MCP get an `evaluate_routing` tool that does the same pure evaluation. 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

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

:::note
Dry runs evaluate rules, they do not exercise ingest. Authentication, field mapping, and batch fan-out only run on a real request to the source URL, so finish with step 4 before trusting the pipeline end to end. See [The generic webhook source](https://firefight.app/docs/alerts/generic-webhook.md).
:::

Related pages: [Routing rules](https://firefight.app/docs/alerts/routing-rules.md), [How alerts work](https://firefight.app/docs/alerts/how-alerts-work.md).