Catalog is our powerful engine, enabling seamless automation of configurations across both On-call and Response products. At its core, Catalog lets you map your organization’s structure, allowing us to route alerts to the appropriate teams, support customer-facing teams in identifying the right contacts, and streamline configuration to accelerate migration.
Catalog offers flexibility and versatility to meet your needs, along with default settings to help you get started. Integrating a third-party service catalog, like Backstage, is also quick and easy.
How we page
When something goes wrong, it’s essential to involve the right people immediately. Paging or escalation can happen automatically from your alert source or manually by someone initiating a page or an incident
In both cases, to ensure the right people are paged, it’s essential to connect your Catalog types with the correct escalation paths. For example, you can link Teams, Services, and Features to their respective escalation paths for streamlined paging.
Escalating and creating incidents automatically from your alerts
Once your Catalog is set up with types connected to escalation paths, you can configure Alert Routing to dynamically route escalations to the appropriate team and individual.
This means that you can use one route for even 100 teams without creating separate configurations to each.
Head to alert route
Go to escalations
Escalate via dynamic value
Create an expression ie. From Services > Teams > Escalation paths
Save
Now every time an alert comes in, we'll read what service it will have and route it depending on that to the right team!
💡 Learn how to automatically escalate and create incidents here
Escalating and creating incidents manually
When a customer reports an issue, team members often need to manually escalate or create an incident. They can do this through the web dashboard or by using the /inc or /inc escalate commands. With Catalog, customer-facing teams don’t need to know exactly who owns a feature; they can simply escalate based on the feature, and the Catalog will route it to the correct team.
💡 Learn how to manually escalate and create incidents here
Configuring your Catalog
To set up your Catalog with On-call, we’ve created simple defaults to help you get started. In this section, we’ll share some example structures to guide you along the way!
1️⃣ Determine the structure of your Catalog
The structure of your Catalog depends on your system and organisation structure. A common simple structure is
Teams
That own Services
That includes features
For larger companies, there might be more grouping of teams into domains
Domains
That includes teams
That own Services
That includes features
2️⃣ Create them as Catalog Types
After you have decided on which Types you need, it's time to import those types from your third-party service catalog or manually create them.
3️⃣ Connect types to Teams
To ensure your On-call configuration functions correctly, connect all necessary types using Attributes and Derived Attributes, which can be edited within each Type. Make sure the Type is selected from the Catalog and is not set as Text or String.
💡 The Catalog is very flexible and can be used in thousands of different ways to suit your company, so please contact us if you have a specific use case you'd like to run through with us at [email protected]
Parsing Catalog values from alerts
To finalize setup, ensure the metadata from your alerts—such as labels—connects with the Catalog entries you've created for your types. Here are some examples of how alert metadata can map to your Catalog:
Alert > Service > Team > Escalation Path
Alert > Feature > Team > Escalation Path
Alert > Team > Escalation Path
etc...
Attributes
When setting up your alert source, start by sending an initial payload that includes the typical metadata for your alerts. Next, organize this metadata so it can drive escalations and other automated actions on the platform—these elements are called Attributes.
You can create Attributes that connect to Catalog types or store them as text as needed. If your Catalog is already configured, we’ll automatically identify matches and suggest attributes based on those entries.
Aliases & External IDs
Sometimes, your payload may use different names or formats for the same metadata. The External ID is how your systems identify this entry, and it cannot be changed once set.
Use Aliases to reference this Catalog entry across other tools. Aliases should be unique and permanent, allowing you to rename the Catalog entry without changing the alias."
💡 Aliases are helpful when names change, such as a team name update. This allows you to change the name of your type while adding the previous name as an alias, ensuring continued recognition without interruption.