Teams
Grouping people so that alerts reach the group that owns the thing.
Incidents & On-Call → Teams groups people, and gives services an owner.
Why
Ownership answers the question every alert implies: whose is this? A service with no owning team produces alerts that reach either everybody or nobody, and both are a way of reaching no-one.
A team
| Name | What the team is called in conversation |
| Members | With roles, if you use them |
| Services owned | What alerts route here by default |
| Schedule | The team's on-call rotation |
| Escalation policy | The team's default |
| Channels | Where team-wide notifications land |
Ownership drives routing
Once a service has an owning team, alerts about it route to that team's schedule and policy with no per-rule configuration. New rules on that service inherit it.
This is the main reason to set ownership: it makes the correct routing the default, rather than something each rule has to remember.
Team membership is not a role
A person's role is what they may do. Team membership
is who gets paged. They are unrelated — a viewer can be on call, and an
admin need not be on any team.
Related
- On-call schedules
- Escalation policies
- Analytics — response times by team, which is where an overloaded team becomes visible
Where this behaviour lives: frontend/src/app/teams/, backend/internal/handler/team_handler.go. If the code and this page disagree, the code is right — please fix the page.
Part of Incidents and on-call — Turning a reading into a page, and a page into a resolved incident.