---
title: "Service catalog"
description: "A structured map of what you run, who owns it, and where to find them, so incidents route to the right people automatically."
canonical: https://firefight.app/docs/catalog/overview/
---

# Service catalog

The catalog is Firefight's answer to the two questions every incident starts with. What is this thing, and who owns it? You record your services, teams, and environments once, and Firefight uses that map everywhere. Alerts route to the owning team, incident forms offer your real services as options, and connected AI agents can answer "who owns checkout?" without anyone digging through wikis.

The catalog lives at **Catalogue** in the dashboard sidebar. The main page shows a grid of your catalog types with an entry count on each card. Click a type to see its entries in a table, add new ones, or open an entry to inspect its attributes.

## The four built-in types

Every workspace starts with four types. They are the vocabulary the rest of Firefight understands, so alert routing and catalog enrichment key off them directly.

| Type | What it holds |
|---|---|
| Team | Teams that own and operate services, with a Slack channel, a manager, and members |
| Service | Services and applications in your infrastructure, each with an owner team, a tier, and a repository |
| Environment | Deployment environments, with a production flag and a region |
| Functionality | Business capabilities and product features, each with an owner team |

Built-in types come with a sensible set of attributes out of the box, and you can add more. Their identity is fixed so that routing and enrichment always know where to look, but everything else about them is yours to shape. See [Entries, attributes & relationships](https://firefight.app/docs/catalog/entries-and-attributes.md) for the full attribute list on each type.

## Custom types

The four built-ins rarely cover everything. Click **Create Type** on the Catalogue page to add your own, such as Vendor, Database, or Feature Flag. A custom type gets a name, a description, an icon, a color, and any set of attributes you define, including references to entries of other types. Custom types behave exactly like built-in ones in the dashboard and the API.

:::tip
Start small. A catalog with ten real services and their owning teams already powers owning-team alert routing. You can grow it from there.
:::

## What the catalog unlocks

A filled-in catalog is not documentation for its own sake. It drives concrete behavior.

- Alert routing can invite the owning team of the affected service and notify its channel. See [Putting the catalog to work](https://firefight.app/docs/catalog/using-catalog.md).
- Custom fields on incidents can offer catalog entries as their options, so "Affected service" is always a real service.
- The API and connected AI agents can read the catalog, so external tools and agents share the same map you do.