One engineering team documented their channel going from 43 Linear notifications per day down to 8 after building a simple priority filter - and even that broke within two months when their Linear workflow changed. The native integration wasn't the problem. How they were running it was.
The Linear Slack integration is one of the most installed, most muted tools in an engineering team's stack. The default configuration treats every issue state change as equally urgent as a direct mention. It isn't. Here's what the integration actually does, where the friction compounds, and what a good setup looks like.
What the Linear Slack integration actually does
The integration has four distinct parts: channel subscriptions (a Slack channel subscribes to Linear events scoped by team, project, label, or status), the /linear slash command (which lets a Slack user create an issue from inside a thread, with the thread linked back for context), message shortcuts (turning any Slack message into a Linear issue in two clicks), and URL unfurling (rendering Linear issue links inline with status, assignee, and latest update).
When you create issues from Slack, the comment thread is bidirectionally synced with a thread in the issue - particularly useful for keeping people reporting issues informed even if they don't have a Linear account.
Team notifications post updates to a specific Slack channel for issue activity, including issue creation, comments, status changes, and project updates. That last sentence is where things go wrong.
Why the notification volume breaks channels
The fundamental problem isn't that Linear sends too many notifications. It's that the integration has one volume knob set to maximum. You can choose which teams and projects feed into which 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 but alert on Blocked." The granularity stops at event type, and that's one level too coarse.
The predictable workaround is to split notifications across team-specific channels.
#eng-frontend, #eng-backend, #eng-platform, #eng-mobile - it was sending every update, faithfully, in real time, and nobody was reading any of it.
Building a webhook-to-Slack middleware to filter by priority works better in the short run. A channel can go from 43 notifications per day to about 8 - but maintenance is a pain. Every time the Linear workflow changes (a new state added, a label renamed, teams reorganized), the filter rules need updating. After two months, they drift enough to miss events they should catch and catch events nobody cares about.
That's not a focus problem. It's a notification design problem. When the signal-to-noise ratio is too low, humans adapt by filtering everything out - including the alerts that actually matter.
The one event type worth keeping real-time
Here is the non-obvious split most teams miss: when someone comments on a Linear issue and @-mentions a Slack user or links to a Slack thread, that notification goes to the relevant channel in real time. Comments are the one event type where real-time notification actually matches how people work - someone asked a question and needs an answer, or shared information that's time-sensitive. Everything else - state changes, assignments, priority updates, new issues - can be batched into scheduled summaries.
What works instead of the firehose is a small scheduled rhythm: a morning standup-style summary of open and in-progress issues, an afternoon post covering anything in a Blocked state, and a Friday cycle report. A project lead who used to compile that Friday report manually now gets it in Slack at 4pm and reviews it in five minutes.
Nobody has muted the engineering channel since the switch. That's the metric that matters more than any configuration detail. A channel that people actually read is infinitely more valuable than a channel that faithfully logs every event into the void.
Beagle in action#eng-general, 9:05amLinear Asks: when not everyone has a Linear account
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, and each Ask becomes an issue in Linear where teams can triage, prioritize, assign, and respond using their existing workflows.
Once enabled, 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. That distinction matters for cross-functional teams: a marketing manager can file a bug report or data request without a Linear seat, and the engineering team triages it from Linear's inbox rather than hunting through Slack threads.
Asks created from Slack keep a synced comment thread between Linear and Slack, so replies in either place stay connected. The requester never needs to check Linear - updates come back to the same thread where they asked.
Slack Asks is available on Business and Enterprise plans, with additional features available to Enterprise workspaces through Advanced Linear Asks.
| Capability | Native Slack integration | Linear Asks |
|---|---|---|
| Issue creation from Slack | Yes, via shortcut or slash command | Yes, via /ask, emoji, or DM |
| Requires Linear account | For issue creators, yes | No - any Slack user |
| Bidirectional comment sync | Yes | Yes |
| Structured intake templates | No | Yes |
| Real-time notifications | Yes (all events, by default) | Updates back to originating thread only |
| Triage inbox in Linear | No | Yes |
| Available on free plan | Yes | No (Business/Enterprise) |
The right pattern: use the native integration for your engineering team (capture via slash command, comments real-time, everything else batched). Add Linear Asks for the cross-functional intake layer - product feedback channels, IT help desks, design request queues.
Linear Slack integration: common questions
How do I reduce Linear notifications in Slack without losing the important ones?
Keep real-time notifications on for comments only - that's the one event type where immediacy matters. Turn off state changes, assignments, and new issue alerts, and replace them with a scheduled daily summary of open issues and a separate afternoon post for anything in a Blocked state. Most teams find three to five daily channel messages replace forty.
Can people without Linear accounts create issues from Slack?
Yes, but only through Linear Asks, not the base integration. Once Asks is enabled, 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 base slash command and message shortcut integration requires a Linear account to authenticate.
What does bidirectional sync mean in the Linear Slack integration?
When you create issues from Slack, the comment thread in Slack is bidirectionally synced with a thread in the issue - useful for keeping people reporting issues informed even without a Linear account. The synced thread in Slack is also updated when the issue is completed or cancelled. Replies you leave in Slack appear in Linear, and vice versa.
Does the Linear Slack integration support multiple Slack workspaces?
Linear's Enterprise plan supports connecting multiple Slack workspaces to Linear. On Business and below, it's a one-to-one connection: one Linear workspace, one Slack workspace.
What is Linear Asks and how is it different from the standard integration?
Linear Asks is designed for internal requests that might otherwise get lost across chat threads, shared inboxes, and ad hoc forms. It's especially useful for engineering teams receiving bug reports from non-technical teammates, IT and support teams handling hardware and access requests, and product teams collecting feature requests. The standard integration is built for engineers who live in Linear. Asks is built for everyone else.