Putting the catalog to work

The catalog pays off in three places. Alerts route by ownership, incident fields stay structured, and the same map 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.

Tip

For owning-team routing you need exactly three things. The alert’s service field matches a service entry’s slug, that service has its Owner Team set, and the team has its Slack Channel, Members, or Manager attributes filled in.

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.

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.
• 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 Settings → API Keys, and access is read-only.

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.