How to rotate Linear triage so it doesn't burn out one person
Turn on Triage Responsibility in Team Settings, add the people who should share the duty, and connect a schedule if you want the handoff to happen automatically instead of by memory. Linear's own Triage documentation describes the feature as letting you "select specific members of your workspace to receive notifications of new issues or be automatically assigned to them," and it connects directly to PagerDuty, OpsGenie, Rootly, or Incident.io schedules so the on-call person rotates without anyone editing a list by hand.
That answers the mechanical question. The harder one is why teams need this at all. Triage is, by design, the place where unfiltered incoming work lands, and unfiltered incoming work is unevenly distributed across the week. Leave it assigned to one person permanently and you've built a job that's mostly interruptions, with no schedule that says when the interruptions stop. A teardown of Linear's triage model puts it plainly: "Triage is interrupt-heavy by nature, so leaving it on one person forever burns them out. Rotate the duty." The fix isn't complicated, but it has three parts, and most teams only do the first one.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat Linear's Triage actually watches
Before setting up a rotation, it's worth knowing what lands in the queue the rotation is protecting. Per Linear's docs, issues enter Triage automatically when they're created through a connected integration (Slack, Sentry, Intercom, Front, or Zendesk), filed by someone outside the team via Asks forms, or created directly in the Triage view itself. Everything else, issues created normally within the team, skips Triage and goes straight to the backlog.
That matters for sizing the rotation. A team with three integrations feeding Triage and a public Asks form gets a different volume than a team using Triage only for internal escalations. Check what's actually wired in under Team Settings before deciding how many people the duty needs.
Step 1: turn on Triage Responsibility and name the group
Under Team Settings > Triage, enable Triage Responsibility and add the members who'll share it. This is the setting that makes "who owns this right now" a fact the whole team can see rather than an assumption. Linear's docs note that teammates "will be able to easily see who is currently assigned to monitor triage when creating issues," which cuts down on the duplicate pings that happen when two people both think they're covering.
Start with three to five people if the team is big enough to support it. A rotation of two just relocates the burnout to every other week.
Step 2: connect a real schedule instead of a manual list
A static list of names tells you who's supposed to be on triage this week, but someone still has to remember to check the calendar and swap the assignment. Linear's integration with PagerDuty, OpsGenie, Rootly, and Incident.io removes that step. Connect an existing on-call schedule and the responsible person updates automatically as shifts change. Linear added support for PagerDuty's newer shift-based (v3) schedules in addition to classic layer-based (v2) schedules back in June 2026, so a schedule built either way syncs correctly.
If the team doesn't already run one of those tools, Linear's API is the fallback. You can build a custom rotation against it, though at that point you're maintaining scheduling logic Linear or one of those providers already solved.
Step 3: require priority before an issue leaves Triage
Rotation fixes who looks at new issues. It doesn't fix what happens after they look. Under Team Settings > Triage, there's a separate option to require a priority be set before an issue can move out of Triage into the team's normal workflow. Turn it on. Without it, a triager under time pressure will accept an issue into the backlog with no priority attached, and it becomes indistinguishable from everything else the moment it lands, which defeats the point of having triaged it at all.
A rotation that held up: Loomsbury's on-call swap
Amara Sekou leads a four-person engineering team at Loomsbury, which builds scheduling software for home-health agencies. For its first year, Triage sat entirely on one back-end engineer because he'd set up the Zendesk integration and it felt like his responsibility by default. By the following spring he was quietly avoiding Mondays, when the weekend's Zendesk backlog and the weekly Sentry noise both landed in Triage at once.
Amara's fix used the two settings above. She turned on Triage Responsibility for all four engineers, connected the team's existing PagerDuty schedule so the assignment rotated with the same weekly on-call shift they already used for incidents, and required priority before anything left Triage.
Amara summed it up afterward for her team: "Nobody's dreading Mondays anymore because Monday isn't always the same person's problem. The thing I didn't expect is that requiring priority caught two issues that would've sat in the backlog with zero context. Now they can't leave Triage without someone deciding how urgent they actually are."
The rotation didn't reduce how many issues arrived. It just made sure the same person wasn't opening all of them.
What a fair rotation still doesn't fix
A rotation distributes the queue evenly. It doesn't shrink the queue, and for a lot of teams, the queue is the actual problem. Three limits show up predictably once volume grows:
- Everything that reaches Triage still needs a human read. A rotation of five people each reading 40 issues a week is better than one person reading 200, but it's still 200 issues nobody has pre-sorted.
- Duplicate reports still cost a full triage pass each. Linear's Triage doesn't dedupe incoming issues against each other, so the fifth report of the same bug from a different Slack channel or Zendesk ticket shows up as a fresh item, and whoever's on rotation triages it as new.
- The requester's context often doesn't survive the trip. An issue filed from a Slack integration carries the message text, but not always which account asked, whether they're a paying customer, or that this is the third time this month someone's raised it.
That third point is where teams add something ahead of Triage rather than inside it, and it's the part we build. Modem watches Slack, Zendesk, Intercom, and the rest of a support stack, groups the same request together across channels before it ever becomes an issue, and attaches the people and companies who raised it. By the time something reaches Linear, it's a counted topic with quotes and a requester list attached, not a raw message, which means whoever's on the triage rotation that week is triaging fewer, better-labeled issues instead of more raw ones. Modem doesn't replace Triage Responsibility or the rotation settings above; it changes what has already been filtered by the time your rotation sees it. Pricing is unlimited users on every plan, so adding it doesn't turn into a per-triager cost the way seat-based tools do.
Two related guides worth reading next: is Linear enough for managing customer feedback on its own, and whether Linear catches duplicate feature requests automatically, which covers the dedupe gap above in more depth.
Two settings, no schedule tool required
Turn on Triage Responsibility, add everyone who should share the duty, and require priority before an issue can leave Triage. That's two settings, and it's enough to stop the queue from resting permanently on whoever set up the integration first. Add a real schedule once the manual list starts slipping.
