On day one of connecting Linear to Slack, one 18-person engineering team watched 43 notifications hit their #engineering channel before lunch. By the end of week two, 14 of 18 engineers had muted it. The integration was working exactly as designed. That's the problem.
The Linear-Slack integration is genuinely well built. But there's a failure mode so common it has its own arc - and most teams hit it in the same order. If your Slack channel for Linear feels like a bot that nobody reads, you're not missing a setting. You're running the integration wrong.
What the Linear-Slack integration actually does
The integration offers several types of notifications for Slack. You can enable personal notifications so that inbox notifications also go to Slack. Team and project notifications can be directed to dedicated Slack channels to keep everyone in the company updated, regardless of whether they have Linear accounts.
That covers the notification side. But notifications are only one of four things the integration handles:
-
The /linear slash command lets a Slack user create a Linear issue from inside a Slack thread, with the thread linked back to the issue for context. Message shortcuts let you turn any Slack message into a Linear issue in two clicks.
- When you create issues from Slack, the comment thread in Slack is bidirectionally synced with a thread in the issue - particularly useful for keeping users informed even if they don't have a Linear account.
- Links from Linear sent in Slack expand to show a preview with key properties such as description, status, and assignee for issues and description, status, and target dates for projects.
- You can mention @Linear in discussions on Slack to take actions in Linear based on your conversation's context, using natural language to specify details or simply letting the agent infer what's needed.
The integration earns its keep when teams use the slash command and message shortcuts for capture, not just notifications. Most teams that find the integration disappointing are running it as a one-way notification firehose and missing the parts that actually save time.
The notification volume problem and why filtering alone doesn't fix it
The integration has one volume knob and it's set to maximum. You can choose which teams and projects feed into which Slack channels, and you can pick which event types to include. But you can't say "only notify me about high-priority state changes" or "batch these updates into a daily summary" or "skip In Progress notifications but alert on Blocked." The granularity stops at event type, and that's one level too coarse.
The typical troubleshooting arc teams run through:
- Split into sub-channels.
#eng-frontend, #eng-backend, #eng-platform, #eng-mobile. This reduced per-channel volume by about 75%, which helped - but each channel still had the same signal-to-noise problem at a smaller scale. Engineers still saw every state change for every issue in their scope, and still muted the channel within a few weeks.
Restrict event types. Turning off assignment notifications and state changes, keeping only comments and new issues, cut the volume dramatically - but killed the visibility the PM wanted. She couldn't track engineering progress from Slack anymore, which was the whole reason the integration had been set up.
Build a webhook middleware. A small service that received Linear webhooks, applied filters (only notify on Urgent or High priority issues, only notify on Blocked state), and forwarded filtered events to Slack. This worked - the channel went from 43 notifications per day to about 8. But maintenance was a pain. Every time the Linear workflow changed - added a state, renamed a label, reorganized teams - the filter rules needed updating.
This is the non-obvious insight hidden in the noise problem: the native integration's filtering model is scoped to event type, but the actual signal teams care about is scoped to priority + state combination. A "status changed" event on a P3 In Progress issue is noise. A "status changed to Blocked" on a P1 is urgent. The integration treats them identically.
The structural fix: one channel per scope, one audience per channel
The right fix isn't filtering - it's architecture. Most teams that try the Linear-Slack integration and decide it doesn't work hit the same failure mode: one channel collects every notification from a Linear team, the volume climbs past fifty messages a day, people mute the channel, and the integration is running but effectively dead. The fix is structural.
A setup that works for most engineering teams uses four distinct channels:
| Channel | Linear subscription | Audience |
|---|---|---|
#eng-triage |
Issues created with bug, customer-reported, or production labels |
On-call rotation |
#eng-cycle |
Issues moved to In Review or Done in active cycle | Current cycle team |
#project-x |
Status changes and milestone updates for one initiative | That project group only |
#bugs-intake |
No subscription - inbound capture only via slash command | CS, sales, support |
Volume in a project channel is naturally low because projects don't change status often. A capture-only channel for bug intake from non-engineers uses the slash command and message shortcut to file Linear issues from a customer-success or sales channel. The channel doesn't subscribe to Linear events - it does inbound work, not outbound.
Where Linear Asks changes the intake equation
Linear Asks helps organizations manage internal requests that would otherwise be scattered across chat, email, and ad hoc forms. Once enabled, people can submit an Ask through Slack, email, or web forms. Each Ask becomes an issue in Linear, where teams can triage, prioritize, assign, and respond using their existing workflows.
The key difference from the standard Slack integration: anyone can create an Ask to send their request to the relevant Linear team via Slack, even if they don't have a Linear account. The standard integration requires a Linear seat to create issues. Asks removes that wall.
Linear Asks converts Slack messages into Linear issues using emoji, /asks, or @Linear Asks. Templates support bug reports, IT tickets, HR requests, feature ideas, customer success asks, and data requests. Synced threads keep Slack replies, files, status changes, and assignee updates tied to the Linear issue.
The Linear Asks agent does not rely on default templates - it will pick the appropriate template based on the user's message. That's a meaningful design choice: the agent reads intent rather than asking the submitter to self-classify. In practice it means someone in #support who types "the export button is crashing for enterprise customers" gets routed to an engineering team, not left to figure out which template applies.
Linear Asks is available to workspaces on Business and Enterprise plans, with additional features available to Enterprise through Advanced Linear Asks.
Beagle in action#customer-success, 2:07pmThe gap the integration still doesn't close
Even with Asks and bidirectional sync, the integration leaves one gap that teams feel daily: context collapse. When a bug is reported in Slack, the relevant history - three previous similar reports, a related PR, a comment from a customer call - lives across threads, channels, and issues. The person triaging still has to gather it manually before they can write a useful issue.
Linear now supports connecting its MCP server to Slackbot so it can access your Linear data when you ask it questions in Slack. A Slack admin adds Linear as a custom MCP server in Slackbot's connector settings. This is the right direction - a model that can read across Linear and Slack simultaneously - but it requires admin setup and puts the work on the person asking, not on the tool surfacing the context proactively.
A teammate like Beagle can bridge that gap: when a bug surfaces in Slack, it can read the thread, search related Linear issues, and draft a complete, linked issue ready for one-tap approval - rather than waiting for someone to manually assemble the picture.
Linear Slack integration: common questions
Why does my Linear Slack integration feel like a firehose?
The native integration's filtering stops at event type - you can mute "status changed" events entirely, but you can't filter to only "status changed to Blocked on a high-priority issue." The fix is structural: one dedicated channel per audience and scope, not one channel receiving all events from a whole team.
Can non-Linear users create issues from Slack?
Yes, but only through Linear Asks, not the standard Slack integration. Only users with Linear accounts can create issues in Slack using the standard Linear integration. Linear Asks, available on Business and Enterprise plans, lets any Slack workspace member submit a request that becomes a Linear issue in triage.
What is Linear Asks and how is it different from the standard Slack integration?
Linear Asks is a feature that integrates Slack with Linear, allowing users to convert Slack messages into actionable tasks or issues. It simplifies how you manage workplace requests such as bug reports, IT tickets, feature ideas, and more. The key difference is that Asks works for people without Linear accounts and routes requests into a triage queue with templates and assignee rules, while the standard integration requires a Linear seat for issue creation.
Does thread sync actually work both ways?
Asks created from Slack keep a synced comment thread between Linear and Slack, so replies in either place stay connected. Updates post back to the original Slack thread automatically when an issue status changes or is resolved - the requester never needs to open Linear.
What does the @Linear agent in Slack actually do?
Linear Agent considers instructions you write in Slack integration settings on how to create issues. You can give it context about your channel naming structure, how it relates to your Linear projects, what statuses you prefer it to create in, and the team it should use when unsure. In practice, it lets anyone mention @Linear in a thread to create or query issues using natural language - the agent infers team, priority, and status from context.