Service catalog

A service catalog is a list of all services or product functionalities and their respective owners or subject matter experts. More advanced service catalogs also include things like rollback plans and documentation for each service. The aim of a service catalog is to help incident response teams quickly bring in the owner or expert related to an impacted service or functionality during an incident.

What is a service catalog?

A service catalog is a centralized and structured list that notes an organization's services, including details about their dependencies, criticality, and expected performance. For incident response, a service catalog helps teams quickly identify the owners of impacted services and pull them into response efforts.

Documenting this information prevents knowledge silos and ensures everyone has the information they need to move forward confidently — allowing everyone to move more quickly toward mitigation efforts.

Why is a service catalog important?

When your incident response process is centered around a service catalog, responders are able to more quickly pinpoint the service or functionality that’s down, bring in the team or experts, and then get to solving the problem faster. Saving even a few minutes can have a big impact on decreasing the costs around incidents and outages, so having up-to-date service details at your fingertips can make all the difference. So it’s no surprise that the Incident Benchmark Report showed that incidents with services attached to them had a 36% decrease in MTTR (mean time to resolve), across severities, compared to those with no services attached.  

What are the benefits of a service catalog?

A robust service catalog is an essential tool in the overall incident management ecosystem and can significantly enhance your team’s productivity. It’s not surprising that our Benchmark Report found a 1640% increase in services created over the course of 2022.

Benefits include:

• Improved incident resolution times: Referencing a service catalog during incident management means teams can quickly identify and resolve issues, reducing resolution times.

• Consistent incident handling: A service catalog standardizes the procedures for managing incidents and creates consistency across incident management processes, increasing efficiency and reducing the risk of errors.

• Production readiness: Mature service catalogs also enable process automation to ensure newly created services adhere to requirements set by the engineering organization.

Get started with a service catalog

If you're building a service catalog from scratch, start simple; list all the services with their owning and responding teams, contact details, repositories, documentation, and monitoring dashboards.

You can still use a service catalog if you're managing a monolith instead of microservices. Break down any monoliths by module, components, or product surface area. Each product area should have an engineering team, and those teams should be trained on your incident response process.

Once you've got the simple service details and dependencies out of everyone's head, you can start to add valuable layers to your catalog. Add functionalities, like login or checkout, on top of the services that power them. Organize by functionality because that's how your customers think. They're not concerned with what service is broken; they're concerned that they can't log in.

This approach has the added benefit of involving more people in your organization during incidents without requiring them to know the technical details of your system.

If you're just starting out, you can store your service catalog in a company wiki or a shared document for easy reference. However, if you're new to documenting a formal incident response process altogether, taking the time at the beginning to center it around your services will deliver better results as you mature your program.

Consider setting up your process so that when an incident is declared and you find out what's broken, it's clear which team member needs to be alerted. Perhaps this can even be done automatically.

Take your service catalog to the next level

When they are most valuable, service catalogs are treated as more than a directory; they are valuable tools for aggregating institutional knowledge. The ultimate goal is a fully fleshed-out service catalog that includes dependencies, owners, and links to operational documentation. Once you have the basics in place, there are several steps you can take to level up.

• Create space for documentation: Users should be able to quickly find out what a service does, who created it, what recently changed, and all other information associated with it. Dedicate a space in your service catalog for documentation of past incidents and events.

• Map services to runbooks: Seriously speed things up by connecting your services to runbooks. For example, Avalara mapped a runbook to each service the company monitors, which helps the team get the right people in the right place at the right time faster, as well as document service-specific nuances and processes for the many applications monitored. When a service goes down, the corresponding runbook is triggered, and everyone jumps into action. 

• Consolidate information: Update your service catalog as your organization grows (there are tools that make this easier) to ensure a streamlined, focused incident response process. Information consolidation ensures that new hires and unfamiliar teams can access the same valuable historical data and context as your most experienced engineers. 

Automating service catalogs

Consider the on-call engineer responding to an incident: If they have a fully built-out service catalog, they can access the most critical information on the affected service and who to contact with a single glance. And if that service catalog is integrated into their incident response and alerting tools, they can even bring in the owner of the affected service or functionality the second an incident is declared. Many invest in a service catalog solution because it can lead to significant operational efficiency. 

You don’t necessarily need a dedicated tool, especially if you’re just starting out. However, if you’re new to documenting or standardizing your incident response processes, taking the time at the beginning to center it around your services will deliver better results when you start to mature your program.

Solutions like FireHydrant’s Service Catalog provide a streamlined way to define and update your services with configuration options, including the ability to ingest services and service metadata from third-party systems. 

Additionally, maintaining a service catalog with solutions like FireHydrant enables you to track services affected by a specific incident. This information allows you to customize your incident response based on the services impacted.