Teams
Organize workspace members into teams for group notifications and escalation targeting.
Teams let you group workspace members together so you can notify an entire group at once — through escalation policies, for example. Instead of adding individual users as escalation targets, you target a team, and all members are notified.
How Teams Work
A team is a workspace-scoped group of users. When a team is used as an escalation step target, every member of the team receives a notification. Teams are the simplest way to ensure that a group of people — an SRE team, a platform squad, a product team — all hear about an incident simultaneously.
Team Settings
| Setting | Required | Description |
|---|---|---|
| Name | Yes | Human-readable name for the team (e.g., "Platform Engineering", "SRE On-Call") |
| Description | No | Optional description of the team's responsibility |
Team Members
Each team has a list of members. A member is a workspace user who has been added to the team.
- A user can belong to multiple teams.
- Each user can only be added to a team once (enforced by a unique constraint on team + user).
- When a user is removed from the workspace, they are automatically removed from all teams (cascade delete).
Adding Members
Removing Members
Select the member and click Remove. The member is immediately removed and will no longer receive notifications routed through this team.
Using Teams in Escalation Policies
Teams are one of four escalation step target types. When an escalation step targets a team:
- Ionhour resolves all current members of the team.
- Each member is notified through their configured contact methods.
This is useful for "all hands" escalation steps — for example, step 2 of your policy might notify the entire platform team if the on-call engineer doesn't acknowledge within 5 minutes.
Example: Escalation Policy with Team Target
| Step | Delay | Target | Purpose |
|---|---|---|---|
| 1 | 0 min | On-call schedule | Notify whoever is on-call |
| 2 | 5 min | Platform Engineering team | If not acknowledged, notify the whole team |
| 3 | 15 min | PagerDuty channel | If still not acknowledged, page leadership |
Teams vs. On-Call Schedules
| Feature | Teams | On-Call Schedules |
|---|---|---|
| Who is notified | All members, always | One person at a time (the current on-call) |
| Use case | Group awareness, backup escalation | Primary incident response |
| Rotation support | No | Yes (daily, weekly, custom) |
| Override support | No | Yes (temporary coverage swaps) |
Use on-call schedules for "who is the primary responder right now?" and teams for "notify everyone in this group."
Best Practices
- Keep teams small and focused. A team of 3-6 people is ideal. Large teams (10+) dilute ownership — everyone assumes someone else will respond.
- Mirror your org structure. Create teams that map to your actual squads or service ownership. This makes it natural to assign escalation policies.
- Use teams as a backup tier. The most common pattern is: step 1 targets an on-call schedule (one person), step 2 targets the team (everyone). This balances focused response with group awareness.
- Review membership regularly. When people leave the team or change roles, update the team membership. Stale teams that include people who no longer own the service create noise.