How to Set Up Incident Management in Linear
Linear is primarily a product engineering tool, but many engineering teams adapt it for incident management because of its speed, label system, and Slack integration. Incidents are, after all, high-priority issues that need fast triage and clear ownership — which is exactly what Linear handles well.
This guide covers how to build a lightweight incident management workflow in Linear using labels, triage, automations, and post-mortem tracking.
Step-by-step guide
Create an Incidents team or project
Create a dedicated Linear team called "Incidents" or "On-Call" that is separate from your product team. Set the workflow statuses: Reported > Triaging > Mitigating > Monitoring > Resolved > Post-Mortem. This team is exclusively for production incidents, keeping them separate from feature work.
Define severity labels
Create a Severity label group: SEV-0 (total outage, all users affected), SEV-1 (major feature broken, significant user impact), SEV-2 (degraded experience, workaround exists), SEV-3 (minor issue, minimal impact). Every incident gets a severity label immediately at creation. This drives escalation rules.
Set up Slack automations
In Team Settings > Automations, create rules: when a SEV-0 or SEV-1 issue is created, send a Slack message to #incidents with the title, severity, and assignee. When status changes to Resolved, post a resolution message. When an issue stays Triaging for more than 15 minutes with no status change, escalate to the on-call lead.
Create an on-call assignment workflow
Create a recurring Linear cycle representing each on-call week. The on-call engineer is the default assignee for all new issues in the Incidents team during that cycle. At the start of each week, rotate the on-call by changing the default assignee. This makes on-call handoffs explicit.
Track post-mortems as linked issues
When an incident is resolved, create a linked Sub-Issue called "Post-Mortem: [incident name]." Move this sub-issue to a Post-Mortem status. Assign to the incident lead with a 48-hour due date. The post-mortem links back to the incident issue, creating a permanent connection between the event and the learnings.
Common mistakes
Mixing incidents with the product backlog
Incidents filed directly into the product team's backlog compete with feature work for attention. A dedicated Incidents team creates clear separation: on-call engineers own the incidents team, product team owns the backlog. Priority decisions do not conflict.
No severity assignment at creation
An incident without severity has no urgency. Severity must be assigned within 5 minutes of creation — even if it changes later. An incorrect severity that gets corrected is better than no severity. Escalation automations depend on it.
Skipping post-mortems
The post-mortem is where incidents pay dividends. Skipping it means the same incident recurs. Budget 48 hours after resolution for a written post-mortem. Even a 200-word blameless post-mortem that identifies one action item prevents repeat incidents.
Tips
Link incidents to the Linear project or PRD that shipped the broken feature for root cause context
Use Linear's Slack integration to let anyone create an incident from a Slack message with one click
Review resolved incidents weekly to identify recurring themes and prioritize reliability work
How Vantage helps
Vantage generates tickets with clear acceptance criteria and dependency tracking. Well-defined tickets reduce the likelihood of incidents caused by ambiguous requirements or missed edge cases. When incidents do occur, the Vantage-generated PRD context helps engineers understand the original intent of the feature being debugged.