How to Set Up SLA Tracking in Linear
Linear does not have a built-in SLA engine, but its combination of custom labels, cycle time metrics, and saved views gives engineering managers everything they need to track service-level commitments without a separate tool.
This guide covers how to model SLA tracking in Linear using label-based priority tiers, filtered views that surface at-risk issues, and the team workflow that prevents SLA breaches from being discovered after the fact.
Step-by-step guide
Define your SLA tiers and response targets
Before configuring Linear, define your SLA structure: P0 (Incident) — acknowledged in 30 min, resolved in 4 hours; P1 (Critical Bug) — acknowledged in 2 hours, resolved in 24 hours; P2 (High) — first response in 1 business day, resolved in 5 business days; P3 (Medium) — resolved in the current or next sprint. Write these as a team agreement document and link it from your Linear workspace description.
Create SLA priority labels
In Linear workspace Settings → Labels, create labels that encode SLA tier: "P0: Incident," "P1: Critical," "P2: High," "P3: Medium." Use a consistent color scheme: red for P0, orange for P1, yellow for P2, blue for P3. These labels are separate from Linear's built-in Priority field — use Linear Priority for sprint planning and these SLA labels for customer-facing SLA commitments. Create a label group called "SLA" to keep them organized.
Build at-risk SLA views
Create saved views in Linear that surface at-risk issues: P0 Issues (filter: label is "P0: Incident" AND status is not Done — no grouping, sorted by Created date ascending), P1 At Risk (filter: label is "P1: Critical" AND created more than 20 hours ago AND status is not Done), SLA Report (filter: any SLA label AND created in the last 14 days — sorted by Created ascending, grouped by label). Pin these views to the team sidebar so they are visible in every standup.
Track cycle time using Linear analytics
In Linear team Settings → Analytics, review the Cycle Time chart which shows time from "In Progress" to "Done" per issue. Filter by label to see cycle time per SLA tier. Export this data monthly. Compare the median cycle time per tier against your SLA targets. A P1 issue with a 24-hour SLA target and a median cycle time of 18 hours is healthy. A P2 with a 5-day target and median cycle time of 12 days needs intervention.
Create the escalation workflow
Set up a Linear automation (Settings → Automation) with the trigger "Issue label added" for P0 and P1 labels. Action: add the issue to a dedicated "SLA Escalations" project and post a Slack notification to the #incidents or #engineering-alerts channel. Create a recurring calendar event (or use a Linear notification reminder) that fires every 2 hours for any open P0 issue and every 6 hours for P1 issues. Assign an on-call EM as the default assignee for unassigned P0/P1 issues using Linear's triage workflow.
Common mistakes
Confusing Linear Priority with SLA tier
Linear's built-in Priority field (Urgent, High, Medium, Low) is for sprint planning — it determines what gets worked on next. SLA tiers are about customer commitments — they determine how fast something must be resolved. Using the same field for both creates conflicts when a P2 SLA issue is not actually the next sprint priority. Keep them separate with dedicated SLA labels.
No acknowledged state in the workflow
SLAs typically have two components: time to acknowledge and time to resolve. Linear does not have a built-in "Acknowledged" status but you can add one to your workflow. The moment an engineer comments on a P0/P1 issue or moves it to "In Progress," the clock on acknowledgment stops. Without an explicit acknowledged state, you cannot report on acknowledgment compliance separately from resolution compliance.
SLA views that no one looks at
Creating a saved view that shows at-risk SLAs is useless if no one opens it. Make SLA review a standing item in every standup: open the P0 and P1 At Risk views and walk through them in 2 minutes. This creates a forcing function so at-risk issues get attention before they breach, not after.
Tips
Use Linear's built-in "Due date" field on P1 issues set to exactly 24 hours from creation — Linear's overdue filtering then automatically surfaces breached SLAs without a custom view
Create a monthly "SLA Report" Linear project that aggregates all P0 and P1 issues resolved in the month — use this as the basis for a monthly reliability summary shared with stakeholders
Add the SLA label to the issue template so every new bug report automatically includes a placeholder SLA label that the triaging engineer updates — this prevents unlabeled issues from falling outside your SLA tracking entirely
How Vantage helps
SLA tracking in Linear captures engineering reliability. Vantage connects SLA data to the product: when recurring P1 issues cluster around a specific feature area, Vantage surfaces this as a pattern that should inform the roadmap. A PRD for a reliability improvement is stronger when grounded in actual SLA breach data rather than general engineering intuition.