Connect Linear and Slack
Linear keeps engineering moving, and Slack is where the team talks about it in real time. Connecting Linear and Slack in NoClick pushes issue and project updates into the channels people watch, and lets Slack activity create or comment on Linear issues. It keeps everyone aware of engineering progress without anyone refreshing Linear.
Linear + Slack automations
Pick one to start building it.
About each integration
Templates connecting Linear and Slack
PostHog Exception Triage Agent
Files one Linear issue per exception with the events the user triggered just before it, a session recording link when PostHog captured one, and a queried count of how many people hit it. An exception with a minified stack and nothing around it is a puzzle; the same exception with the four things the user clicked before it is a bug report. This agent reads the person's event trail, runs one query to find out whether this hit one person or nine hundred, attaches a session recording where PostHog captured one, and files a single Linear issue with all of it in a fixed order. Impact is a number that came back from a query, so nobody argues about it from the shape of the error message. ## What people use it for - **Reproduction steps for free** - The events leading into the exception are the steps, in the order a real person did them, including the flags that were on for them. Engineers skip the part where they guess how anyone reached that screen. - **One person or nine hundred** - A query counts distinct persons and occurrences over your window, so severity is a figure written into the issue rather than an impression formed from the wording of the error. - **Watch the bug happen** - Where a recording covers that person at that moment, its link goes into the issue. Thirty seconds of replay settles arguments a stack trace leaves open all week. - **Extension noise stays noise** - Exceptions whose frames all belong to a browser extension or a third party script are reported with their counts and no theory attached, and your triage rules decide whether they are worth an issue at all. ## Before you fork **We already have an error monitor. Why triage exceptions in PostHog?** Because the context lives here. PostHog knows the pages, the clicks and the flags around the exception, and often has a replay of it, which is the difference between a stack trace and a bug somebody can reproduce. If you run both tools, point this at the exceptions where nobody can work out what the user did. **Will customer data end up in Linear?** People are identified by their PostHog id, and the instructions keep emails, names and other personal fields out of the issue body. The event trail is pages and actions rather than form contents. If your events carry sensitive properties, name them in the triage rules and they stay out too. **How much extra PostHog querying does this add?** One person lookup, one short event list, one aggregate query and one recording check per exception the trigger sends, which is small next to normal ingestion. You decide how many exceptions reach the trigger in the first place. Rehearsing on the staged exceptions first shows you what a day of this looks like before you point it at everything.
Linear Cycle Progress Digest
Answers the cycle question worth asking on day four rather than day fourteen: is this cycle keeping pace with the last one, what has stopped moving, and what got added after it opened. You can tell a cycle went badly on its last day, which is the one day nothing can be done about it. Every morning this agent reads the running cycle against the two before it and posts the numbers that show whether the team is roughly where it usually is by now, together with the work that has gone quiet and the issues that landed after the cycle opened. It is a health read rather than a task list, and it names the issues so the conversation has somewhere to begin. ## What people use it for - **See the slip on day four** - Holding today next to the same day of the last cycle turns a vague feeling that things are dragging into a number, with a week and a half still left to do something about it. - **Find the work that went quiet** - Anything in progress past your threshold is listed with its age and its owner. Long lived in progress issues are where cycles leak, and they hide on a board because they look exactly like work happening. - **Make late arrivals countable** - Nine issues landing on a Thursday after a customer escalation is worth having in writing when the cycle closes short. The agent lists them and adds no editorial of its own. - **Works on teams that never point** - Plenty of Linear teams leave every estimate empty. The digest counts issues and labels the figures as counts, rather than presenting a number that quietly mixes estimated work with unestimated work. ## Before you fork **We do not use estimates. Is this any use to us?** Yes, and it expects that. With estimates empty it counts issues and says on the line that these are counts, so nothing silently blends pointed work with unpointed work. Teams that do estimate get the same headings computed from their own estimate field instead. **How is this different from Linear's own cycle graph?** The graph shows the shape once you open it and remember to. This arrives in the channel your team already lives in, names the specific issues that produced the shape, and holds the previous cycle up beside the current one so a slow opening week is legible on day four. Run both, they answer different questions. **What can it change in Linear, and what do the runs add up to?** Nothing at all. Its Linear access is read only: no edits, no comments, no cycle changes, so a mistake shows up as an odd line in Slack and never as a moved issue. One run each morning per team you point it at, whether the cycle holds twenty issues or two hundred, so what you pay tracks the number of mornings and nothing besides.
Sentry Error Triage Agent
Turns every new Sentry error into a scored, duplicate checked Linear ticket with the real user and event counts in it, and only pings the channel for the ones your rules call severe. Sentry is very good at telling you something broke and very bad at telling you whether it matters, so teams end up either filing everything or filing nothing. This agent reads the issue, its recent events and your release history, scores it against the severity rules you write, and files one Linear ticket with the impact numbers, the failing frame and the suspected release already in it. Engineers get a ticket they can start on, and the alert channel only rings at the top of your scale. ## What people use it for - **Catch the bad deploy** - When an error first appears minutes after a release, the agent names that release in the ticket and, if your rules call it severe, in Slack. The link between the deploy and the spike is made while it still matters. - **One ticket per bug** - Linear is searched for the same error signature before anything is filed, so a recurring error links back to the ticket that already exists instead of stacking three duplicates in the backlog. - **Tickets with the evidence in them** - Impact, location, stack, first and last seen and the suspected release are written into the issue body in a fixed order, so nobody has to open Sentry to decide whether to pick it up. - **Separate noise from severity** - Nine events from three users on a nightly job is not two thousand events on checkout. Your severity rules make that call every time, and only the top level is allowed to interrupt anyone. ## Before you fork **What do I need to connect before this works?** A Sentry credential with read and write on issues in the projects you want triaged, a Linear key for the team you file into, and a Slack channel for severe errors. Your severity thresholds and a short description of the services and their owners go in as variables. Nothing about your existing alert rules changes except which of them you forward here. **What does it cost to run, on a noisy project?** It runs on the errors your Sentry rule sends, so the volume is yours to set. A rule that fires on new issue groups rather than on every event keeps this to a handful of runs a day even on a busy service. Start with one project, watch a day, then widen. **Can it close or hide errors I still need?** No. It never resolves, ignores, merges or deletes a Sentry issue, and the only write it makes there is linking the Linear key back in. It reports evidence rather than a diagnosis, so it will tell you which frame throws and which release it started after, and it will not name a cause or a commit. When an error sits between two severity levels it takes the lower one and says why, so the channel stays quiet by default.
Daily Engineering Digest Agent
Posts one Slack digest every weekday morning covering what shipped, what is stuck and who is waiting on a decision, pulled straight from Linear. Standup exists because nobody can see across teams. Every weekday morning this agent reads the last day of Linear activity for the teams you name and posts one Slack message: what shipped, what moved, what is stuck and who is waiting on a person. It is for engineering leads tired of asking for status, and it holds up because it never guesses - every line points at a real issue. ## What people use it for - **Replace the status standup** - Gumloop posts a 24 hour summary to Slack each morning and stopped asking people for updates. This is that digest for Linear, so standup starts from what everyone already read. - **Catch stuck work on day three** - Anything blocked or untouched for three days lands in the STUCK section with what it is waiting on, so a blocker gets named while it is still a day of delay and not a week. - **Give leadership one place to look** - Your team context tells the agent what leadership actually asks about, and the same digest answers it every morning. Nobody writes a status update by hand again. - **Cover every team at once** - Shopify ran issue digests across 110+ teams. Name three teams or ten and each gets its own lines, including the ones that had a quiet day, which is usually the useful signal. ## Before you fork **What does it need connected?** A Linear credential with read access to the teams you want covered, and a Slack channel to post in. During setup you describe your teams, who owns the digest, and how blunt you want it. The agent only reads from Linear, it never changes an issue. **Can I change when it runs, and what does that cost?** The schedule step controls the time and timezone, and it is set to weekday mornings so Monday automatically covers the weekend. That is roughly 22 runs a month, one per working day, regardless of how many issues your teams move. Moving it to twice a day simply doubles that. **What if the digest says something wrong?** It reports what Linear says and nothing else, so a wrong owner or a stale status in the digest is a wrong owner or stale status in Linear. It will never invent an ETA or a reason for a stall, and if a team returns nothing or a call fails it says so in a NOT SEEN line rather than quietly omitting the team.
Databricks Job Failure Agent
Files one Linear issue per failed Databricks run with the error copied out exactly, says whether the job has failed once, flakes, or has been broken since Tuesday, and names what downstream just went stale. A failed Databricks run tells you almost nothing on its own, and the question that actually decides your morning is never in the alert: has this job failed before. This agent pulls the run output, reads the last runs of the same job, and writes one Linear issue that says first failure, flaky, or broken since Tuesday, with the error text copied out exactly and the downstream tables you told it about. Whoever picks it up starts from evidence rather than from a red square on a dashboard. ## What people use it for - **First failure or the usual** - Run history is read first, so a job that has quietly failed every night since a schema change is labelled as such, and the one that just broke for the first time is not lost among them. - **The error, character for character** - The exception class and message are copied out of the run output unedited, which is what makes an issue searchable later and what lets the next person match it against a vendor bug report. - **Downstream owners named upfront** - Your runbook notes attach tables, dashboards and owners to each job, so the issue says what is now stale instead of leaving that to be discovered by whoever opens the dashboard at nine. - **One issue per broken job** - Linear is searched for the job and the exception before filing, so an hourly job failing all afternoon leaves one issue and a pattern, not fourteen tickets somebody has to close by hand. ## Before you fork **Does it need permission to run or restart jobs in Databricks?** No. It reads runs, run output and job definitions, and that is the whole of its Databricks access, so a token scoped to read is enough. The writing all happens in Linear and Slack. If you later want automatic retries, that is a separate workflow and a deliberate decision rather than a side effect of triage. **We run hundreds of jobs a night. How often does this actually fire?** Once per failed run, not per run, so cost tracks your failure rate and not your job count. A platform with a few failures a night is a few short runs a night. Jobs you have already accepted as flaky can be marked low stakes in the runbook notes, so they still file an issue without pinging anyone. **What stops it filing the same issue every hour?** Every run begins with a Linear search on the job name and the exception class, and an open match stops it filing. The history check also gives the failure a name, so a persistent break reads as one problem with a date on it rather than as a fresh incident each hour. You can rehearse it against the staged failures before it writes to your real Linear team.
Linear Issue Triage Agent
Empties your Linear triage view as issues arrive: existing labels applied, the right engineer assigned, lookalikes linked by identifier, and one comment asking for the detail nobody remembers to include. Linear teams file fast, which is the point, and it also means the triage view fills with one line issues carrying no labels and the same crash reported by three people who each thought they were first. This agent reaches every issue as it is created: it searches the workspace for that symptom, applies labels you already use, assigns from your area map, and asks once for the build number or workspace id that is missing. Opening Linear becomes a review of triage rather than the doing of it. ## What people use it for - **Triage view at zero** - Issues are labelled and owned within a minute of being filed, so the view your team is supposed to clear each morning is already clear. Nobody draws the short straw at standup. - **Catch the lookalike first** - A workspace search runs before a single word is written, so a re-report arrives with the original identifier quoted in the comment instead of turning into a parallel investigation two engineers pursue separately. - **Ask for the build number once** - Issues filed from Slack shortcuts and support handoffs almost never carry version, platform, or workspace id. The comment names exactly the ones missing, so the reporter answers in a line. - **Break the room only for outages** - Slack fires for issues that clear the urgent bar you wrote and nothing softer, quoting the issue identifier, its title, and whatever cleared that bar. ## Before you fork **Will it start inventing labels in our workspace?** No. It reads your existing label list on every run and can only apply what is already there. If your guide names a label nobody has created yet, the agent says so in the comment instead of creating one, which keeps label sprawl a decision your team makes deliberately. **What happens when the search finds something similar that is not actually a duplicate?** It writes the identifier into the comment as a possible duplicate and stops. It never merges, never closes, and never marks a relation, because deciding two reports are the same bug takes context the agent does not have. Two seconds of a human reading one line beats an auto merge you have to unpick. **What does it need connected, and what does a run cost?** A Linear credential that can read and update issues in the team you want triaged, plus a Slack channel for the urgent ones. It runs once per issue created, and a run is a search, a couple of reads, and one comment, so cost follows how many issues you file and not how big your workspace is. A team opening 25 issues a day is 25 small runs a day.
Frequently asked questions
More integration pairings
Connect Linear and Slack in minutes
Build it visually with NoClick, or describe what you want and let AI assemble the workflow. No code required.