Why teams matter
Almost everything in Warrn is anchored to a team. When an alert fires, Warrn looks at the service it came from, finds the team that owns that service, and uses the team’s on-call schedule and settings to decide who gets paged.
Organization
└── Team
├── Members who is on this team
├── On-call who is reachable when
├── Services what this team runs
│ └── Alerts what's going wrong on a service
└── Knowledge runbooks and docs the team owns
Creating a team
Go to Teams in the sidebar and click New team. You need the admin role on your organization to create one. A team needs a name and an optional description.
Roles
| Role | What they can do |
|---|
| Admin | Edit the team. Add and remove members. Create and delete services owned by this team. Acts as the fallback on-call if no schedule is set. |
| Member | View everything in the team. Acknowledge and resolve alerts. Take part in incident response. Cannot edit team settings or remove other members. |
What lives on a team
- On-call - schedules, rotations, escalation policies, and overrides.
- Alert intelligence - AI Triage, Auto-Group, and past-alerts lookback.
- Integrations - alert sources, Slack, Jira, Confluence, etc. attached at the team level.
- Knowledge - runbooks and notes that belong across the whole team. Services have their own knowledge trees for things specific to one service.
Deleting a team
Admins can delete a team from its detail page. Services owned by the team become orphaned and need to be reassigned to keep alerts routing. Members stay in the organization. On-call schedules are deleted. Past alerts and incidents stay in the system for history.
If you’re not sure whether to delete or rename, rename first. Deletion is irreversible.
