An alert fires on a shared platform component that three product teams depend on. How do you decide which team's on-call the page routes to, and what has to exist for that routing to be correct?

## The question behind the question When an interviewer asks how a shared dependency's page gets routed, they are checking whether you understand that paging is an ownership statement. Every page asserts: *this specific human can do something about this*. Routing that violates the assertion is how teams end up with pagers they have learned to ignore. ## One page, one owner The default is that an alert routes to the on-call of the team that owns the component the alert is about, because that team is the one that can act. For a saturated shared database, that is the platform or data team who owns the database — not the three product teams whose queries are slow because of it. The tempting alternative, fanning the page out to every dependent team, is worse in three specific ways: - **Cost.** One incident becomes three or four woken engineers, and pager load is a real budget you are spending. - **Diffusion of responsibility.** When four people are paged, each assumes one of the others has it. Ownership becomes ambiguous exactly when it needs to be sharp. - **Learned helplessness.** A team repeatedly paged for something they cannot fix stops reading those pages, and the next page they ignore will be one they could have fixed. Consumers still need to *know*. The right channel for them is notification, not paging: a message into their incident or team channel, a dependency-status update, or a mention in the incident channel. A consuming team pages its own on-call when its own user-facing SLI degrades — that is their alert firing on their service, which is a separate routing decision with a separate owner. ## Ownership metadata is the real prerequisite Routing correctness is downstream of a data problem: does a machine-readable record exist saying which team owns which service? In practice that is a service catalog or ownership file with, per service, exactly one accountable team, the paging target for that team, an escalation policy, and ideally a tier or criticality. Two properties make it stay true: 1. **It lives next to the code** and changes through review, so an ownership change is part of the change that caused it. 2. **It is the source that generates routing**, rather than being documentation that drifts from what the paging tool actually does. If the catalog and the paging tool disagree, the paging tool wins at 3am and the catalog is a lie. ```yaml services: - name: shared-postgres-primary owner_team: data-platform tier: 1 routing_key: data-platform-high-urgency - name: payments-api owner_team: payments tier: 1 routing_key: payments-high-urgency default_route: owner_team: platform-oncall action: page_and_open_ownership_ticket ``` "Exactly one" matters. Shared ownership between two teams reliably degrades to no ownership, because each team's escalation assumes the other acked. If two teams truly share a component, name one as the paging owner and let them pull the other in. ## Orphan alerts The routing defect that shows up in real postmortems is the orphan: an alert whose target is a team that was reorganised out of existence, a schedule with nobody on it, or a service that was inherited and never re-tagged. The page fires into a void and is discovered hours later. Design so orphans are loud: - Give the routing rules a **catch-all** at the end that pages a platform or infrastructure on-call, and that also opens a ticket to assign a real owner. The catch-all should be slightly embarrassing to hit, so it gets fixed. - **Audit periodically** for schedules with gaps, escalation policies whose targets no longer resolve, and services in the catalog whose owning team no longer exists in the org directory. - **Re-verify routing after every reorg.** Reorgs are the leading cause of broken paging, and nobody thinks of the pager on the day the teams change. ## Routing by urgency as well as by owner Ownership picks the team; urgency picks the delivery. The same owning team usually has at least two entry points: a high-urgency route that goes to the escalation chain and rings a phone, and a low-urgency route that lands in a queue or channel for working hours. Routing decisions are two-dimensional, and getting the owner right while sending everything down the high-urgency path is how a team ends up with a healthy ownership model and a wrecked rotation. ## What good looks like in an answer Name the ownership record, insist on a single accountable team, describe telling consumers without paging them, and volunteer the orphan case and the post-reorg audit. That combination is very hard to produce without having lived through a page that went nowhere.