What is a service catalog?

A service catalog is a central inventory of every service an organization runs, with ownership, dependencies, and operational metadata for each one. It helps engineers find who owns a service, how to page them, and how it is deployed during incidents.

What is a service criticality tier?

A criticality tier ranks how important a service is to the business, usually from Tier 1 (an outage causes direct revenue or safety impact) down to Tier 4 (best-effort). The tier drives SLA targets, on-call expectations, and review rigor.

Can I use this entry in Backstage?

Yes. The generated Markdown captures the same fields Backstage and similar developer portals expect, so you can paste it into a wiki page or use it as a checklist while filling in a catalog-info.yaml file.

Why list dependencies explicitly?

Documented dependencies let responders trace failures upstream and downstream during an incident, and they make blast-radius analysis possible. Listing each dependency on its own line keeps the entry parseable and easy to scan.

What belongs in the runbook link field?

It should point to the operational runbook for the service — the document that explains how to restart it, common alerts, and recovery steps. Pairing the runbook with the on-call contact gives a responder everything needed to act fast.

Internal Service Catalog Entry Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

A catalog entry without the blank-page problem

A good service catalog is only useful when every service has a complete, consistent entry. This builder turns a short form into a clean, structured Markdown record covering ownership, reliability targets, API surface, dependencies, deployment, and on-call — the fields responders actually need at 3am during an incident.

How it works

You fill in the service identity (name, owner team, criticality tier, language, repository) and a one-line description. The tool derives a stable catalog ID by lowercasing the name and replacing spaces with hyphens. You then add reliability targets (availability SLA and latency SLO), list API endpoints and dependencies one per line, and provide deployment notes, a runbook URL, and an on-call contact. The builder assembles all of this into ordered Markdown sections so the same shape is reused for every service, which is what makes a catalog searchable and trustworthy.

Tips and example

Keep endpoint lines in METHOD /path — purpose form so the catalog reads like lightweight API docs.
Put one dependency per line — for example postgres-payments then stripe-gateway — so blast-radius tooling can parse them.
Match the criticality tier to your on-call policy: a Tier 1 service should always have a paging contact, not just a Slack channel.
Reuse the same catalog ID as your repo and deploy names so a responder can jump between them without guessing.