Parent epic: #45
Architectural direction
Incident Management v2 separates technical alert processing, operational incidents and on-call duty responsibilities:
Alert -> AlertGroup -> Incident
Team -> OnCallRole -> Schedule -> Rotation / Layers -> Members
On-call roles are separate from RBAC roles and from concrete roles assigned inside a specific Incident.
Architecture document: docs/architecture/incident-management-v2.md
Goal
Allow one team to have several simultaneous on-call users covering different operational functions, while keeping the existing schedule/rotation model and making Incident assignment, escalation and Event Orchestration role-aware.
Scope
- Add team-owned
OnCallRole.
- Add built-in roles:
primary, secondary, incident_responder, incident_commander, customer_communications, ticket_responder.
- Allow team-owned custom roles such as Database SME, Network Responder or Security On-call.
- Assign one On-call Role to each schedule.
- Allow several schedules with different roles to be active for the same team simultaneously.
- Allow several schedules to share one role when concurrent coverage is required.
- Keep On-call Roles off the User model; one user may cover several roles by participating in several schedules.
- Migrate every existing schedule to the built-in
Primary On-call role without changing its rotation behavior.
- Resolve current on-call users by team, role and timestamp.
- Allow role resolution to return zero, one or several users.
- Update the calendar to show role, schedule, user, shift interval and overrides.
- Add calendar filters for team, On-call Role, schedule and user.
- Allow escalation policies to target an On-call Role.
- Allow Incident workflows to resolve current users by On-call Role and then create normal Incident assignments.
- Do not keep a live Incident ownership link to the schedule: later rotation handoff must not silently replace users already assigned to the Incident.
- Add API, OpenAPI, RBAC, audit, localization and migration coverage.
On-call Role versus Incident Role
On-call roles answer:
Who is currently expected to perform this function?
Incident roles answer:
Who is actually performing this function in this Incident?
Recommended mappings:
incident_commander -> Incident commander
incident_responder -> Incident responder
customer_communications -> Incident communications role
custom OnCallRole -> selectable Incident responder role
Resolving an On-call Role copies concrete users into the Incident. Schedule changes after assignment do not mutate the Incident automatically.
API expectations
GET /api/on-call-roles
POST /api/on-call-roles
GET /api/on-call-roles/{id}
PATCH /api/on-call-roles/{id}
DELETE /api/on-call-roles/{id}
GET /api/on-call/current?team_id={team_id}&role={role_slug}
Existing schedule APIs expose on_call_role_id.
Do not introduce an additional OnCallTrack model unless a concrete requirement cannot be represented by multiple schedules sharing the same role.
Acceptance criteria
Dependencies
Parent epic: #45
Architectural direction
Incident Management v2 separates technical alert processing, operational incidents and on-call duty responsibilities:
On-call roles are separate from RBAC roles and from concrete roles assigned inside a specific Incident.
Architecture document:
docs/architecture/incident-management-v2.mdGoal
Allow one team to have several simultaneous on-call users covering different operational functions, while keeping the existing schedule/rotation model and making Incident assignment, escalation and Event Orchestration role-aware.
Scope
OnCallRole.primary,secondary,incident_responder,incident_commander,customer_communications,ticket_responder.Primary On-callrole without changing its rotation behavior.On-call Role versus Incident Role
On-call roles answer:
Incident roles answer:
Recommended mappings:
Resolving an On-call Role copies concrete users into the Incident. Schedule changes after assignment do not mutate the Incident automatically.
API expectations
Existing schedule APIs expose
on_call_role_id.Do not introduce an additional
OnCallTrackmodel unless a concrete requirement cannot be represented by multiple schedules sharing the same role.Acceptance criteria
Primary On-call.Dependencies