How alerts work

Firefight receives alerts from your monitoring tools over HTTP, evaluates them against routing rules you define, and turns the ones that matter into incidents. Everything in between, deduplication, grouping, and notification, is designed so that a noisy night produces one incident and one conversation instead of a wall of pings.

The pipeline

Every alert follows the same path.

1. Your monitoring tool sends a POST request with a JSON body to an alert source URL you created in Settings → Alert Sources. Each source has its own URL and secret token.
2. Firefight verifies the token, then extracts a set of normalized fields from the payload, such as title, service, severity_raw and status.
3. Duplicate detection runs first. A repeat firing of an alert that is already open updates the existing alert instead of creating a new one. See Grouping & deduplication.
4. Routing rules evaluate against the alert’s fields. Rules run in order and the first match wins. See Routing rules.
5. The matched rule’s outcome runs. It creates an incident, attaches the alert to an existing one, sends a notification without an incident, or drops the alert.

Sources

You pick a provider when you add a source, and it decides how Firefight reads the payload and checks the token.

Many tools have a dedicated source that reads their own webhook and resolves alerts when the tool does: Axiom, Better Stack, Datadog, Grafana, Honeybadger, Honeycomb, Logfire, Mixpanel, New Relic, Northflank, OpenStatus, Opsgenie, PagerDuty, PostHog, Prometheus Alertmanager, Sentry and SigNoz. When you create one, Firefight opens its setup with the steps for that tool. For anything else that can POST JSON, use the generic webhook and map its fields yourself.

The edit dialog of every source shows its URL and the steps for pointing that provider at it, under Setup. How the tool proves it is allowed to send depends on the tool:

How the tool authenticates	What the setup gives you
A token in a header or as a password	A Copy token button. Most sources work this way
A signature made with a secret the tool generates, as Sentry does	A field to paste the tool’s secret into. Firefight refuses every request until you save it
No headers at all, as Logfire does	A URL with the secret in it, a Copy URL button and Regenerate address

Disabling or deleting a source

To stop a source taking alerts, edit it and switch off Enabled. Requests to a disabled source’s URL get 404, and switching it back on takes alerts at the same URL again.

A source can be deleted only while it holds no alerts. Once it has received any, Delete in its row menu is greyed out, and hovering it says how many alerts it holds, such as “Checkout has 12 alerts and cannot be deleted. Disable it instead.” The API and the delete_alert_source MCP tool refuse with the same message.

When a tool sends a link to the alert, the alert’s title in Slack, on the incident page and on the Alerts page opens that page in the tool.

Outcomes

A routing rule resolves to one of four outcomes.

Outcome	What happens
Create incident	An incident is declared with a name and summary taken from the alert, at the severity the rule or source mapping resolves.
Attach to open incident	The alert joins an existing incident when one is open for the same alert group. If none is open, nothing is created.
Notify only	A message is posted to a channel, a person, or the owning team’s channel. No incident is created.
Drop	The alert is stored and nothing else happens.

If no rule matches, the alert is stored as unmatched. It creates nothing, but it stays visible so you can see what fell through and tighten your rules.

Grouping prevents storms

When a rule creates an incident, Firefight opens a grouping window. Later alerts whose grouping fields match, for example the same service, attach to that same incident for as long as the window is open instead of creating incidents of their own. One bad deploy that fires fifty alerts becomes one incident with fifty attached alerts. The window length and the fields that define “the same problem” are configurable. See Grouping & deduplication.

Where alerts appear

The Alerts page in the sidebar shows the most recent alerts across all sources. For each alert you see its title, source, firing status, how it was routed, which rule matched, how many times it has fired, and when it was last seen. You can filter by source and by matched rule.

The Routing column says where each alert went.

Routing	Meaning
An incident, such as INC-42	The alert opened or joined that incident. Click it to open the incident
Routed	A rule matched and the alert notified someone or was dropped
Unmatched	No rule matched. The alert was stored and created nothing
Pending	Routing has not finished yet. Firefight retries it automatically every couple of minutes, for example while Slack is not connected yet and an incident cannot open
Failed	Routing failed repeatedly and gave up. Check the matched rule’s outcome, such as its severity

Settings → Alert Sources shows each source’s last delivery under Last received. When the latest request was refused, the cell shows why instead, such as Rejected: invalid token.

If you can manage alerts, each firing alert has a Resolve button. Use it for a tool that never says an alert cleared, such as Mixpanel or Northflank. Firefight resolves the alert the same way it would if the tool had sent the resolve. The alert’s Slack message and the incident timeline say it was resolved, and the incident stays open. Gateway → Activity records who resolved it.

On an incident page, an Alerts panel lists every alert attached to that incident with its firing status, source, fire count, and last-seen time. Alert attachments and resolutions also appear as events on the incident timeline.

In Slack, each routed alert gets a single digest message that updates in place as the alert re-fires or resolves, rather than a new message per firing.

What an alert can start

Beyond routing, an alert can start more work.

• Halon. Under Halon → On-call, Halon can investigate each incident an alert opens and page whoever is on call with what it found. See Halon on call.
• Workflows. A workflow with the Alert received trigger runs once for each alert routing lets through, and once per group for a storm. See Workflows.

Tip

Before pointing production monitoring at Firefight, use the dry-run tools in Settings → Alert Routing to confirm your rules do what you expect. See Testing your routing.