Putting the catalog to work

The catalog pays off in four places. Alerts route by ownership, incident fields stay structured, incidents show on the infrastructure they touch, and the same data is readable by the API and by AI agents you connect. This page covers each payoff and what the catalog needs to contain for it to work.

Alert routing by ownership

When an alert arrives carrying a service, team, environment, or functionality field that names a catalog entry by slug, Firefight enriches the alert with catalog context before routing rules run.

Related entries one hop away are merged in. An alert with only service: checkout also gets team filled from the service’s owner team.
The entry’s attributes become dotted fields, so a rule condition like service.tier is one of Critical routes by catalog metadata the alert never sent.
When you write a condition on a catalog field, the value picker offers your catalog entries directly.

Routing outcomes can then target ownership instead of hardcoded names.

Outcome	What the catalog resolves
Notify the owning team’s channel	The service’s own Slack Channel attribute wins when set, otherwise the owner team’s channel
Invite the owning team	The owner team’s members and manager are invited to the incident channel

Resolution happens at fire time, not when you save the rule. Reorganize ownership in the catalog and every rule follows without edits. When something cannot be resolved, for example a service with no owner team or a team with no channel set, the incident is still created and the gap is recorded as a note on it. See Routing rules for the full rule reference.

Catalog-backed custom fields

Custom fields under Settings → Custom Fields can draw their options from the catalog instead of a hand-maintained list.

A Catalog reference field stores one catalog entry, and a Catalog multi-reference field stores several. Point the field at a type, such as Service, and responders pick from your real services.
Single-select and multi-select fields can also choose From catalogue as their option source, using a type’s entries as the choices.

Attach these fields to the incident lifecycle forms under Settings → Forms and an “Affected services” field becomes structured data that always matches the catalog, instead of free text that drifts.

Incidents on the map

The map shows what runs where, read off your connections. Open a resource there in Focus and choose Link a catalog entry under Runs, from the catalog to say which service it runs, such as the web service on Northflank running your Checkout service.

Once they are linked, an incident that names that catalog service in its fields lights up the resource on the map, and the resource’s panel shows what the service is for, who owns it and how its past incidents ended. A resource with no catalog entry linked cannot show incidents, so linking is what connects the two. See Linking the map to the catalog for everything a link turns on.

Readable by agents and the API

The catalog is part of Firefight’s readable surface for external tools.

The REST API exposes types and entries under /api/v1/catalog/, listed in Entries, attributes & relationships.
Search, with Ctrl K or ⌘K on any dashboard page, finds catalog entries alongside resources on the map, and agents run the same search with search_map.
AI agents connected over MCP get a catalog search tool. An agent investigating an incident can ask which team owns a service, find its Slack channel, and follow relationships between entries, with member attributes resolved to display names. Connections are managed under Developer → API Keys. An agent can also shape the catalog, creating types and writing entries, but only if you granted it that. Read and write are separate abilities, so an agent that only looks things up cannot change them.

Because agents, the API, alert routing, and incident fields all read the same entries, keeping the catalog current in one place keeps every consumer current at once.