Guide
Service ownership
Use Services to record who owns each service. Incidents and the service map then show the team, the contact and the runbook, so whoever is on call knows who to call.
Add an owner#
- Open Services. Every service that sent logs in the last 7 days is listed.
- Choose Add owner.
- Enter the team, a contact and a runbook link, then save.
A name must have sent logs in the last 7 days before it can be owned. This stops a typing mistake from becoming a service.
Merge names#
Names such as orders, orders-svc and Orders_API are often one service. These look like one service lists them with their record counts. Nothing merges until you confirm it, and you can separate a name again.
Merging changes identity, not data:
- The merged name uses the main name's owner.
- A change to any of the names counts as a change to that service on incidents.
- Past incidents match across the names.
- Stored logs keep the names they were sent with, so Explore still shows them as sent.
API#
| Call | What it does |
|---|---|
GET /api/services/catalog | Services, owners, merged names and suggestions. |
GET /api/services/owner?service=… | The owner of a service, through merged names. |
PUT /api/services/owner | Set service, team, contact and runbook_url. |
DELETE /api/services/owner?service=… | Remove the owner. |
POST /api/services/aliases | Merge alias into canonical. |
DELETE /api/services/aliases?alias=… | Separate a name. |
These use your session. Members and above can change them.
MCP#
get_service_owners returns the team, contact and runbook of one service or of all of them.
set_service_owner sets them from an agent (an API key with the alerts scope): service, team, and optionally contact and runbook_url. A name that sent no logs in the last 7 days is refused with the close names that did.