One of the most painful parts of incident response is contextualizing the problem and understanding how and where it fits within your organization. If responders are unable to answer basic questions such as:
- Which team owns a particular service, for example, a checkout page?
- Who should I be paging if an incident affects this feature?
- How do I contact any customers who may be affected by this issue?
Then you waste valuable time talking to the wrong people or solving the wrong problems — ultimately extending impact and hurting your response. It’s a common issue that, up until now, didn’t have a clear solution or workaround.
That’s why we’re announcing incident.io Catalog: everything that exists in your organization, connected together, available everywhere you need it to level up your incident response, including Custom Fields, Workflows, Insights, Triggers and more.
Let’s unpack that:
- Everything: Catalog doesn’t just manage services. It takes care of teams, your CRM customers, upstream payment providers, and more. Whatever you want, you can put it here. When we say “everything,” we mean it.
- Connected: Modern organizations are incredibly connected and complex. Catalog can help you build a graph that knits together all the details of your company in a way that’s just easy to understand. You tell us how everything relates to one another, and we’ll map it for you.
- Everywhere: Our entire product has been rebuilt to be ‘Catalog aware’. Once you’ve given us everything and told us how it’s connected, features like Custom Fields, Workflows and Insights can traverse the data on your behalf. When you raise a critical incident that impacts login on your app, we can find the linked team, jump to their PagerDuty service and page them.
That’s the idea, but the magic of Catalog is best understood with examples. So let’s dig into a few ways you can use Catalog to meaningfully upgrade your incident response.
OK, what can Catalog actually do?
In a nutshell, a lot! But let’s imagine we had a Catalog containing a list of customers, product features, and company teams. In this scenario, our Catalog might look something like this:
With this setup, we are able to:
Track which product features are affected
Custom Fields have been upgraded to take full advantage of Catalog. Now, these fields can power their options from Catalog, ensuring they are always up-to-date and in sync with the rest of your data.
This allows us to create an “Affected features” custom field powered by the “Feature” Catalog type and even group them by the team that owns each feature.
This way, you never have to worry about your list of features being out-of-sync again.
Automatically infer affected teams
Now that we tag incidents with “Affected features,” wouldn’t it be nice if we could automatically infer the “Affected teams” from who owns any of those features?
This is now possible by creating a field set automatically from another, in this case, the owning team of any affected features. This means we can automatically assign the team without ever asking responders, and if they need, it can be manually overridden.
This means more accurate incident data, and less work for teams responding to incidents. A double win!
Build workflows to automate escalations to the right team
We’ve rebuilt much of our product to become Catalog-aware, and Workflows is no exception. Now, when someone in Customer Support raises a critical incident that’s impacting a product feature, we can have a workflow that jumps from product feature to owning team, and from owning team to their PagerDuty Service, where it triggers a page.
Gone are the days of one workflow per team to handle escalations: build expressions that navigate Catalog so you can always bring the right person into the incident at the right time.
Connect your CRM to link incidents to affected customers
It’s now possible to directly connect incidents to the customers they affect by connecting to your CRM directly, such as Salesforce or Hubspot, or loading customer data from your data warehouse.
This allows you to build workflows that fire when “total customer revenue is greater than X” or “email the Account Executive if this incident affects a customer that is in trial”. Or if you’re in fintech, perhaps you have to notify regulators when total payment volume exceeds a threshold: all this is easily done through Workflows.
Or – as we do in our own incident.io account – invite the Customer Success Manager to any incidents that impact customers they manage:
How do I get my data into Catalog?
While you can use our catalog separately from other tools, we’ve designed it to play well with others.
Without any setup required, your catalog will contain resources from your connected integrations – such as GitHub repositories, PagerDuty Services, or Jira Projects – allowing you to build a complete and connected map across your tools.
For those who already have a catalog like OpsLevel, Cortex or Backstage, we’ve built integrations that mean you can sync them into the incident catalog in just a couple of minutes. Once synced, it’s possible to extend these models with attributes specifically tailored to your incident response automations, such as tagging which PagerDuty Services should trigger incident.io incidents.
If you're using Backstage, you can also install our plugin to pull on-going incidents into entity pages, keeping everyone up-to-date:
Finally, we have full support for loading any catalog data from source code or external APIs through either our catalog-importer or the incident.io Terraform provider. Several customers have synced their entire custom-built internal catalogs into incident.io with an hour of work (or less!).
Whatever your situation, we’ve got you covered.
What are customers saying?
Catalog is a big deal for us at incident.io. We’ve always believed that incidents extend beyond just engineering and into the wider organization, and by pushing your organizational map into Catalog, we can help people across teams navigate those structures and respond more effectively.
But don’t take our word for it!
While we’re only announcing Catalog today, we’ve built this alongside some of our most active customers who’ve been testing these features for months.
See Skyscanner, who have a custom in-house catalog they've synced with the catalog-importer:
Having our key data synchronised with incident.io Catalog means we can contextualise what's going wrong, identify hotspots, automate key parts of our response, and provide richer insights too.
It's an incredibly powerful combination.John Paris, Principal Systems Engineer at Skyscanner
Or EFG who use Backstage and are enjoying improved analytics now they can tag incidents against their catalog data:
We already use Backstage as a service catalog so when incident.io released theirs, our top priority was ensuring it played nicely with our existing setup.
Thankfully, this was easy: by using the catalog-importer tool and off-the-shelf templates, we synced our Backstage catalog with minimal effort. Now our catalog is available throughout our incident response and we have a powerful incentive to invest back into Backstage now it’s used to power incident tagging and automations.Bradley Wilson-Hunt, Principal SRE at EFG
To start using Catalog, visit your dashboard to see the types that are already there, try creating a new type by hand, or migrate an existing custom field onto a catalog type. If you're already using a service catalog, be sure to connect it as an integration.
Alternatively, view our interactive product walkthrough that sets up catalog types and demonstrates how to use them in a Workflow, all covered in a 5 minute quick-start guide.
If you have any questions or feedback, drop us a line in your customer channel or let us know what you think @incident_io.
I'm one of the co-founders and the Chief Product Officer of incident.io. I've spent my whole career working in engineering.