---
title: "How alerts work"
description: "The pipeline that turns a webhook from your monitoring tool into a routed, deduplicated incident in Firefight."
canonical: https://firefight.app/docs/alerts/how-alerts-work/
---

# 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`, 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](https://firefight.app/docs/alerts/grouping-and-deduplication.md).
4. Routing rules evaluate against the alert's fields. Rules run in order and the first match wins. See [Routing rules](https://firefight.app/docs/alerts/routing-rules.md).
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.

Two kinds of source exist today. The [generic webhook](https://firefight.app/docs/alerts/generic-webhook.md) works with Datadog, Grafana, Prometheus Alertmanager, or any tool that can POST JSON, using a configurable field mapping. [Northflank](https://firefight.app/docs/alerts/northflank.md) has a dedicated integration.

## 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](https://firefight.app/docs/alerts/grouping-and-deduplication.md).

## Where alerts appear

**Settings → Alerts** 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.

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.

:::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](https://firefight.app/docs/alerts/testing-routing.md).
:::