Service catalog for small teams: one page that says what you run for customers

Every serious ops artifact a small team owns secretly depends on a document they never wrote: the list of services, who owns each one, and what “working” means for it. Incident severity fights happen without it (is the dashboard being slow a P1 or a P2? says who?), the status page drifts into forty-component theater without it, and capacity effort gets spread evenly across services of wildly different importance. A service catalog fixes the root. It does not need a CMDB tool — for a team under fifty, it needs one page with nine rows and a rule that everyone actually follows.

This note gives the one-page catalog, the three-tier system that does the real work, the written “up means” promises that feed your status page, the five traps that turn catalogs into shelfware, and a one-afternoon rollout.

1. The catalog: one row per customer-facing service

Each column earns its place:

• What the customer gets is written in their words, not yours. “Can complete a purchase,” not “payment API 200s.” This column is what you tell customers during an incident, which is why it comes first.
• Tier is the load-bearing column — it decides paging, comms, review cadence, and budget priority (section 2).
• Owner is a person. A team cannot be paged at 3am with a clear conscience; a name can. Every row has a name and a backup name.
• “Up” means is one measurable sentence per service. If you cannot write it, that service has no working definition of healthy — which is a finding about the monitoring, not about the sentence.
• Customers see is the honesty column: either the service appears on the public status page, or it does not, and the row says which. No invisible tier-1 services.

2. Three tiers, and everything hangs off them

• Tier 1 — customers feel it in minutes. Defaults to P1 in the severity matrix, pages the on-call, requires a status-page update inside 15 minutes, gets weekly capacity rows, gets spend priority when headroom runs low.
• Tier 2 — degraded, but a workaround exists or the pain is scheduled. P2 by default, fixes land same or next business day, monthly capacity check, no paging outside hours unless the promise above is breached.
• Tier 3 — internal or cosmetic. No public promise, no paging, best-effort SLA, fixed when it blocks someone. Saying this out loud is the point: a team that treats all services as equally important spends its nights equalizing, not prioritizing.

The tier decides behavior before the incident, which is the only moment it can be decided calmly. The catalog is where that decision is stored so nobody has to re-litigate it at 2am — the same pre-agreement logic as standing orders, applied to infrastructure.

3. “Up” means: the promise in one sentence

Tier 1 and 2 services each get a written promise — one measurable sentence, measured where the customer experiences it (the load balancer, the queue lag, the job completion time), not inside the process where everything looks healthy. The sentence does three jobs at once: it is the component description on the status page, the threshold the error budget spends against, and the definition of “recovered” in a post-mortem. Teams that skip this sentence discover during their first bad night that “the service is up” and “customers can check out” were never the same claim.

4. The five traps

CMDB theater. Two hundred rows with owners like “Platform” and last-modified dates from two reorgs ago is not a catalog, it is a museum. If the page does not fit on one screen, it will not be read during an incident, which is the only time it matters. Nine rows that everyone knows beat ninety nobody maintains.

Tier inflation. Everything becomes tier 1 because every owner argues well. Then tier 1 stops meaning anything, paging spreads evenly, and the genuinely critical service waits behind a broken internal dashboard. The test is brutal and simple: can a tier-1 outage page a human at 3am with no discussion? If that is unremarkable, the list is wrong.

“Up” undefined. A catalog row without a measurable promise just relocates the argument from the incident to the post-mortem. One sentence, measured where the customer feels it, written before it is needed.

Teams as owners. “Owned by Data Platform” resolves to whoever is unluckiest in the room. A name and a backup, on the page, next to the row.

The catalog nobody consults. If incident severity is not assigned by looking up the tier, if the status page components are not the catalog rows, if capacity is not tracked per tier-1 service first — then the page is decoration, and it will rot. The catalog has to be the input to at least three processes you already run, or it is one more stale wiki page.

5. Worked example

A seven-person e-commerce enablement SaaS argues about severity during every incident, lists forty microservices on a status page nobody reads, and split its last quarter's reliability budget evenly across everything. They spend one afternoon on the catalog: nine rows, three tiers, named owners, one-sentence promises for the five tier-1/2 services. The forty-component status page collapses to five components — the five rows customers can actually hold.

The next two incidents prove the page. A nightly ingest backlog that would previously have triggered a 2am all-hands is looked up, found to be tier 1 with a “queue drains in 5 minutes” promise, breached for 40 minutes — P2, status note posted at 9am, no page. Two weeks later, checkout 5xx at 14:10 on a Tuesday: tier 1, P1 by default, first status update at 14:22, engineer paged by name. Nobody argued about either severity. The quiet change is in the budget: capacity rows now exist only for tier 1–2 services, which is where the next infrastructure dollar goes. The counter-example is the sister company that bought a CMDB, seeded it with two hundred services, and held a quarterly review to discover the owners listed had all left.

6. Metrics (for the metric itself)

• The catalog fits one screen; every row has a named owner and a backup.
• Every tier 1–2 row carries a one-sentence measurable “up means.”
• Severity assignments trace to tiers — spot-check the last ten incidents: zero relitigated.
• Status page components equal catalog rows one-for-one.
• The list is re-reviewed quarterly, when services are added or retired — the same pass that updates capacity rows, so the two pages cannot drift apart.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit — incident response for small teams — $14
• Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
• Ops Mega Bundle — all 5 kits in one download — $49

Related: the incident severity matrix is what the tiers feed, the status page template is the public face of the same rows, and the capacity planning template sizes them in the same weekly meeting.