Every serious ops artifact a small team owns secretly depends on a document they never wrote: the list of services, who owns each, and what "working" means. Without it, incident severity gets argued at 2am, the status page drifts into forty-component theater, and capacity effort spreads evenly across services of wildly different importance.
A service catalog fixes the root. For a team under fifty, it needs one page with nine rows — not a CMDB.
You can read the full note on the HIVE80lab ops-notes site — here is the working version.
The catalog: one row per customer-facing service
| Service | What the customer gets | Tier | Owner | "Up" means | Customers see |
|---|---|---|---|---|---|
| Checkout API | can complete a purchase | 1 | Priya | accepts payments 99.9%/mo, p95 < 800ms | status page row |
| Ingest pipeline | their data appears in reports | 1 | Sam | queue drains < 5 min behind | status page row |
| Dashboard web | can log in and view reports | 2 | Marco | < 3s for 99% of sessions | status page row |
| Billing jobs | correct invoices on the 1st | 2 | Priya | completes by 06:00, zero missed accounts | email if missed |
| Internal admin | staff tools | 3 | Sam | best effort | nothing |
The columns that earn their place:
- What the customer gets — in their words, not yours. This is the sentence you tell customers when it breaks.
- Tier — the load-bearing column; it decides paging, comms, review cadence, and budget priority.
- Owner is a person, with a backup name. "Owned by Platform" resolves to whoever is unluckiest in the room.
- "Up" means — one measurable sentence, measured where the customer feels it (the load balancer, the queue lag, the job completion), not inside the process where everything looks healthy.
- Customers see — the honesty column: whether the row appears on the public status page. No invisible tier-1 services.
Three tiers, and everything hangs off them
Tier 1 — customers feel it in minutes. Defaults to P1, pages a human, first status-page update inside 15 minutes, weekly capacity rows, first claim on infrastructure spend.
Tier 2 — workaround exists or pain is scheduled. P2 by default, same-or-next-business-day fix window, monthly capacity check, pages only if the written promise is breached.
Tier 3 — internal or cosmetic. No public promise, best effort, no paging. Saying that out loud is the point: a team that treats every service as equally important spends its nights equalizing instead of prioritizing.
The tier decision is made before the incident, once, and stored — so nobody re-litigates it during one. It is the same pre-written-authority logic as standing orders, applied to infrastructure.
"Up" means: the promise in one sentence
Each tier 1–2 row gets one measurable sentence: accepts payments 99.9% of the month measured at the load balancer, queue drains within 5 minutes, invoices generated by 06:00 on the 1st with zero missed accounts.
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.
The five traps
CMDB theater. Two hundred rows, owners like "Platform," last-modified dates from two reorgs ago. If the page doesn't fit on one screen it won't be read during an incident — the only time it matters. Nine rows everyone knows beat ninety nobody maintains.
Tier inflation. Everything becomes tier 1 because everything feels important to its owner. Then tier 1 means nothing, pages spread evenly, and a genuinely critical outage waits behind a broken internal dashboard. If tier-1 pages are unremarkable, the list is wrong.
"Up" undefined. A row without a measurable promise just relocates the argument from the incident to the post-mortem.
Teams as owners. "Owned by Data Platform" is not an owner; it is a routing delay with a name.
The catalog nobody consults. If severity doesn't trace to tiers, status components aren't the rows, and capacity doesn't start with tier 1 — the page is a wiki ghost. It must be the input to at least three processes you already run.
Worked example
A seven-person e-commerce enablement SaaS spends one afternoon on the catalog: nine rows, three tiers, named owners, five written promises. Their forty-component status page collapses to five components — the rows customers can actually hold.
The next two incidents prove it. A nightly ingest backlog breaches the "drains in 5 minutes" promise for 40 minutes: looked up, tier 1 promise breached but workaround communicated — handled as P2 with a 9am status note, no page, no 2am all-hands. Two weeks later, checkout 5xx at 14:10 Tuesday: tier 1, P1 by default, first status update at 14:22, engineer paged by name. Nobody argued about either severity, because both decisions were made months earlier by a table.
The counter-example is the sister company that bought a CMDB first: two hundred services discovered and entered, quarterly review meetings scheduled, and by the time it was done, three of the named "owners" had left the company. The catalog that fits on a screen was live the same week.
From the HIVE80lab kit
- Score your incident response free — 12 questions, tiered fix-first plan
- 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 rows, and the capacity planning template sizes them tier-first in the same weekly review.
Top comments (0)