What Linear automation does, and exactly where it stops
Linear automates more out of the box than most trackers do after a month of configuration, and then offers almost nothing between that and writing GraphQL. Here is how to work with the missing middle rung.
You moved to Linear partly because the last tracker needed a fortnight of configuration before it did anything useful. Linear did useful things on day one. Now you want it to do one specific thing it does not do, and you have discovered there is no configuration screen to configure, which is the same design decision looked at from the other side.
That is the whole shape of Linear automation, and it is worth understanding as a deliberate choice rather than a gap. Linear ships opinions, not a rule builder. The opinions are good. When you need something outside them, there is no gentle slope: you go from a toggle straight to the API.
What runs without you configuring it
Status categories are the real schema. Your workspace can have any status names you like, but each one belongs to a small category: backlog, unstarted, started, completed, cancelled. Almost all of Linear’s own behaviour keys off the category rather than the name. This matters more than it sounds. If you invent a status and put it in the wrong category, the product will quietly disagree with you forever about whether that work is in progress, and your cycle charts will reflect the category, not your intent. Check the categories of every custom status you have added. It is a five minute audit that resolves a surprising share of “why does Linear think this” questions.
The git integration does the status updating for you. Put the issue identifier in a branch name and Linear connects the two. Open a pull request against that branch and the issue advances. Merge it and the issue completes. Which events map to which statuses is configurable in the integration settings, and the settings are worth opening once rather than accepting the defaults blind, because the difference between “in review on PR open” and “in review on ready for review” is the difference between a useful board and a lying one.
Linear also offers to hand you the correctly formatted branch name from the issue itself, which is the detail that makes the whole thing stick. Conventions that require people to type an identifier from memory decay. Conventions where the tool gives you the string do not.
Cycles roll themselves over. Unfinished work moves to the next cycle without anyone running a ceremony. This is genuinely useful and slightly dangerous: it makes carrying work forward frictionless, and friction was the only thing that used to make anyone notice.
Triage. Incoming work lands somewhere that is explicitly not the backlog, and stays visible until somebody decides. If you have an intake problem, turning this on is a bigger win than any rule you were planning to write.
Housekeeping on a timer. Completed issues get archived after a period, and stale issues can be closed automatically. Both are configurable in workspace settings, and both are the kind of thing you should set once, deliberately, rather than discover later when something you cared about has been tidied away.
No conditional logic
No conditional logic. There is no native way to say “if the label is security and the estimate is above five, add a reviewer and notify this group”. Linear’s automation is a set of behaviours you enable, not conditions you compose. If your request contains the word “if”, the answer is the API.
Nothing time based beyond the built in sweeps. You cannot natively express “flag anything in review for more than three days”. Cycle boundaries and the archive timer are the only clocks you get.
The git integration is per repository and per event. It maps events to statuses. It does not know about environments, so it cannot express the difference between merged and actually deployed. If your definition of done is deployed, the integration will mark things done too early and there is no setting that fixes it.
One workspace, one world. Cross workspace logic does not exist, and if part of your organisation is on a different tracker entirely, nothing described here reaches it.
Worth noting: Linear ships frequently and has been steadily adding capability at this exact boundary. If your workspace offers something more rule shaped than what is described here, that is good news and you should use it rather than trusting an article.
Audit your status categories before anything else
1. Audit your status categories. Before anything else. Half the problems people bring to the API are a custom status sitting in the wrong category.
2. Tune the git integration rather than working around it. Most complaints about Linear statuses being wrong are the default event mapping being wrong for how that team actually works. Open the settings, decide deliberately, and tell people what you chose.
3. Measure your linking rate. The share of merged pull requests whose branch carried an issue identifier. Everything automatic in Linear depends on that link, and the work that never got one is invisible to the board, the cycle chart and every report you build later. If that number is not around nine in ten, no amount of API work will save your reporting, because the API can only see the linked work too.
4. Then, and only then, reach for GraphQL. The API is genuinely good, and webhooks let you react rather than poll. Write one small service, give it a narrow token, make it fail loudly. Do not let it grow into an unowned rules engine one exception at a time, which is exactly what happens when nobody names an owner in the readme.
For teams working inside a single Linear workspace, this is the entire answer. There is nothing to buy here.
Where this breaks down
Linear moves fast, and this article does not. Feature boundaries shift between releases. Treat everything above as the shape of the product, not a specification, and confirm against your own workspace.
The missing middle rung is arguably correct. Every tracker that shipped a general rules engine ended up with organisations running hundreds of rules that nobody can reason about, firing in an order nobody chose, triggering each other. Linear’s refusal to build that has kept a lot of workspaces comprehensible. You may be asking for the thing that ruined the last tool you used.
Automatic transitions weaken the meaning of a status. When a human moves a card, that is a claim. When a merge moves it, that is an inference, and an inference nobody checks. The board stays equally confident whether it is right or wrong, and there is no visual difference between the two states.
Cycle rollover hides a real signal. Work carrying forward used to be a thing somebody had to do, which meant somebody noticed. Now it happens by itself, so the fourth consecutive rollover looks exactly like the first.
The strongest objection: the missing rule might not be worth having. Most requests that hit this wall are automating around a process problem, an unclear definition of done or an intake nobody triages. Fixing the process removes the requirement, and it does not need a token.