What is Triage in Linear?

Triage is a special inbox that each Linear team can turn on to hold incoming issues before they enter the workflow. Issues created by integrations, by people outside the team, or directly in the Triage view land there instead of going straight to the backlog. Someone then reviews each one and decides whether it becomes real work. The point is to keep the backlog made of things the team actually committed to, rather than everything that happened to get filed against it.

What is the difference between Triage and the backlog in Linear?

Triage holds incoming issues that have not been reviewed yet, and it sits outside the normal workflow, so its issues are excluded from standard views and reports by default. The backlog holds issues the team has already accepted as real work, planned but not yet started. Accepting an issue in Triage is exactly what moves it from the first state into the second. In short, Triage answers should this become work at all, and the backlog answers when do we do it.

What does accepting an issue in Triage do?

Accept, with the keyboard shortcut 1, moves the issue out of Triage and into the team's default status, which is what promotes it into the real workflow. It is the only one of the four triage actions that turns an incoming issue into committed work. The other three resolutions are Mark as duplicate, Decline, and Snooze. Set the assignee, priority, and project as you accept so the issue lands ready to work instead of as a bare title.

Linear Triage: A Practical Guide to the Incoming Issue Queue

Q: How do you enable Triage in Linear?

Triage is off until you turn it on, and it is set per team. Open Team Settings, go to the Triage section, and toggle it on. A Triage entry then appears under the team name in the sidebar, and you can jump to it from anywhere with the G then T shortcut. Enable it on teams that receive a lot of integration or cross-team issues, and leave it off on teams that only generate their own work, where it just adds a step.

Q: How do customer support issues get into Linear Triage?

Through integrations. Issues filed by tools outside the team default into Triage, which makes it the natural review point for anything coming from support. For teams where support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker turns a ticket into a Linear issue in one click with the ticket context attached, so it arrives ready to triage, and it syncs status back to the ticket so support knows what was accepted, declined, or shipped.

Connect a few integrations to a Linear team and the backlog stops being a plan. Every Slack escalation, every Sentry alert, and every issue a teammate from another team files lands in the same list as the work you actually committed to this cycle. The signal drowns. Linear Triage is the fix: a holding inbox that catches everything incoming and keeps it out of the real backlog until a person decides it belongs there.

This is a practical guide to the feature, not the general practice of triaging bugs, which is covered in the bug triage guide. Here we cover what Triage is, what routes into it, the four ways to clear an issue out of it, how to keep the queue owned, and how to feed it cleanly from customer support.

In this article

What Linear Triage Is

Triage is a special inbox that sits in front of a team's workflow. Issues that arrive from outside the team collect there instead of dropping straight into the backlog, and each one waits for a person to review it and decide whether it becomes real work. It is enabled per team, so a support-facing team can run it while a team that only generates its own work does not have to.

Triage moves one decision out of the backlog: does this belong in our work at all. Made by accident, that decision fills the backlog with noise. Made on purpose, it keeps the backlog something the team can trust.

The reason this matters is that a backlog only works as a plan if everything in it was put there deliberately. The moment integrations and other teams can write directly into it, it becomes a record of everything that happened rather than a list of what the team chose to do. Triage restores the boundary.

What Lands in Triage, and What Does Not

Triage catches work that originates outside the team. Three sources route into it.

Issues from integrations
Slack, Sentry, and the other connected tools file into Triage rather than straight into the backlog, so an automated alert or a forwarded escalation does not jump the queue ahead of planned work.
Issues from outside the team
When a workspace member who is not on the team creates an issue for it, that issue lands in Triage. The team reviews it before it counts as their work, instead of finding it already sitting in the cycle.
Issues created in the Triage view
Anything you add directly while working the queue starts in Triage, which keeps it consistent with everything else waiting to be reviewed.

What does not land in Triage is the team's own normal work. Issues that team members create through the usual flow go straight to the team's states. Triage is specifically for work arriving from elsewhere, which is exactly the work most likely to be unvetted.

How to Turn Triage On

Triage is off until you enable it, and you enable it per team. Open Team Settings, go to the Triage section, and toggle it on. A Triage entry appears under the team name in the sidebar, and you can jump to it from anywhere with the G then T shortcut.

The Four Ways to Clear a Triage Issue

A triaged issue is not done until it leaves the queue, and there are exactly four ways out. Each has a keyboard shortcut, because Triage is meant to be worked quickly.

1
Accept (shortcut 1)
Accept moves the issue to the team's default status, which is the only action that promotes it into the real workflow. Set the assignee, priority, and project as you accept so it lands ready to work rather than as a bare title that has to be triaged a second time later.
2
Mark as duplicate (shortcut 2 or MM)
Point the issue at the one it repeats, and Linear merges them and cancels the duplicate. This is where the many-reports, one-issue pattern pays off: ten customers reporting the same bug collapse onto a single tracked issue instead of ten, so engineering hears the problem once.
3
Decline (shortcut 3)
Decline cancels the issue, with an optional comment explaining why. A lot of declines are not defects at all, they are feature requests that need a different home and a reply to the person who asked. The feature request system guide covers where those should go instead.
4
Snooze (shortcut H)
Snooze hides the issue from the queue until you choose to see it again. It is for work that is real but not now: you do not want it cluttering the queue, and you do not want to cancel it. Snooze it and let it come back when it is worth a second look.

Triage Responsibility: Who Owns the Queue

A queue with no owner becomes a graveyard. Linear lets you assign triage responsibility so the inbox always has someone accountable for clearing it.

Set who gets the queue
In Team Settings you can designate triage responsibility so new issues notify, or are automatically assigned to, a specific person. The point is that someone always knows the queue is theirs to clear, rather than everyone assuming someone else is watching it.
Rotate it so no one drowns
Triage is interrupt-heavy by nature, so leaving it on one person forever burns them out. Rotate the duty. If you already run an on-call tool such as PagerDuty, Opsgenie, Rootly, or Incident.io, Linear can drive the rotation from it automatically.
Pair it with your support rotation
If you run an engineer-on-support rotation, the engineer on duty is the natural triage owner, since they already hold the week's customer context. The engineer-on-support rotation guide covers that setup in depth.

Triage Versus the Backlog

These two get confused because both hold issues that are not being worked yet. The difference is commitment, and it changes who the list is for.

Triage (incoming, unreviewed)

Holds issues from integrations and outside the team
Nothing here is committed work yet
Excluded from normal views and reports by default
Each issue waits for accept, decline, duplicate, or snooze
Answers: should this become work at all?

Backlog (accepted, planned)

Holds issues the team has accepted
Committed to the workflow, just not started
Shows up in normal views, cycles, and planning
Has an owner and priority once you set them
Answers: when do we do this?

The practical rule is that nothing should reach the backlog without passing through a person first. Triage is that person's queue. Accepting an issue is the moment it crosses from someone else's input into the team's plan, and keeping that crossing deliberate is the entire reason the feature exists.

Feeding Triage From Customer Support

Triage is built for work that arrives from outside the team, and nothing arrives from further outside than a customer. A bug reported in a support ticket is the textbook case: it is unverified, it needs a human accept or decline call, and it should not jump straight into a cycle. The catch is context. A triager clears an issue in seconds when the report carries reproduction steps, the affected account, and a link back to the conversation. They stall when the issue is a one-line title and they have to go chase the reporter before they can even judge it.

If support runs on HubSpot Service Hub and engineering runs on Linear, this is where IssueLinker fits. From the HubSpot ticket, support turns a customer report into a Linear issue in one click, with the ticket context carried over, so it arrives in the engineering team ready to triage instead of as a bare title. Comments and notes sync both ways, so a triager's question reaches the customer without leaving Linear, and when the issue is accepted, declined, or shipped, the status flows back to the ticket so support can close the loop. The full setup is in the Linear HubSpot integration guide.

Send support issues to Triage with the context already attached

If support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker turns a ticket into a synced Linear issue in one click, with the reproduction context and a two-way status loop so the triage decision reaches the customer.

What to Do This Week

If your backlog has quietly filled with work no one chose, three steps start fixing it without changing how the team plans.

Turn Triage on for your highest-inflow team
Start with the team that fields the most integration and cross-team issues. That is where the backlog noise is worst and the payoff from a review step is biggest.
Assign triage responsibility and rotate it
Give the queue a named owner this week, then put it on a rotation so the interrupt load does not land on one person every day.
Route support intake through Triage, not the backlog
Make customer-reported issues land in Triage with their context attached, so engineering accepts them on purpose instead of discovering them already mixed into the cycle.

Triage does not slow a team down. It takes one decision, does this belong in our work, out of the backlog where it was being made by accident, and puts it in a queue where it is made on purpose. That is the whole feature, and on any team with real inbound, it is the difference between a backlog you trust and a list you have given up reading.