Incident work and deployment correlation
Track response tasks, follow-up work, and related deployments.
The incident workspace combines immediate response tasks, longer follow-up work, and nearby deployment evidence. Open an incident from Incidents, or use Incident work to scan work across all incidents (reachable from Incidents → Manage → Work queue).
Tasks
Tasks belong to either the response phase (work needed during the incident) or the follow-up phase (postmortem action items). A task has a title, an Open / In progress / Done state, an optional person or team assignee, an optional due date, and an optional external issue URL. Overdue work is highlighted.
Use response tasks for time-sensitive mitigation and follow-up tasks for work that survives resolution. The incident's postmortem has its own action-item list for lessons and corrective action; choose one system for each piece of work to avoid duplicate ownership. See Postmortems.
The work queue
The Incident work page shows tasks across all incidents. Choose a view:
- My work: open tasks assigned to you or your teams.
- Overdue: open tasks with a past due date.
- Organization follow-up: all follow-up-phase work.
Each row links back to its incident workspace. Task changes are organization-scoped and audited; deleting a task removes that work item rather than the incident.
Deployment evidence
Status finds deployments near the incident and shows service/version, environment, status, linked monitor names, source URL, and a computed health summary. A responder can classify a deployment as:
- suspected: a possible incident cause under investigation.
- contributing: believed to have contributed to the incident.
- unrelated: investigated and excluded.
- rolled back: reversed during response.
The relationship is responder evidence, not an automatic rollback or health transition. Deployment ingestion and API-key permissions are covered in Deployment events.