Linear is where modern teams track work. GitHub is where that work gets done.
The gap between them is where time gets lost. Here are five automation patterns
that bridge the gap — and give engineers an hour back every week.
Pattern 1: CI failure → Linear issue
When CI fails on main, create a Linear issue automatically.
CI fails on main → Create Linear issue: "[Repo] CI failure on main" → Assign to: last committer → Priority: urgent → Include: error message, link to run, commit hash
This ensures every CI failure has an owner. No more "who's going to fix this?"
The issue is already assigned.
Recommended for you
Run these patterns on autopilot
Every pattern here ships as a Deviera template — connect GitHub and Linear and CI failures, PR links, and stale-PR nudges happen automatically.
When a PR is opened, link it to the Linear task it's addressing.
PR opened → Extract task ID from branch (e.g., DEV-123-feature-name) → Add PR link to Linear task → Add comment: "PR created: [link]" → Update task status to "In Review"
Reviewers see the task context in Linear. Developers see the PR status in Linear.
Everyone stays in one tool.
Pattern 3: PR merge → task completion
When a PR is merged, update the Linear task to done.
PR merged → Extract task ID from branch → Update task status to "Done" → Add comment: "Merged to main by [author]"
This closes the loop without manual status updates. The task is done when
the code is merged, not when someone remembers to update Linear.
Pattern 4: Stale PR → reminder
When a PR has been waiting for review for 48+ hours, notify the team.
PR open for 48h without review → Find linked Linear task → Add comment: "PR waiting for review 48h" → Notify: tag reviewer in Slack or Linear
This ensures incidents don't stay open after they're resolved. The Linear issue
reflects the actual state of production.
What else to automate
Beyond these five, consider:
Linear → GitHub label sync: Update GitHub labels from Linear status changes
GitHub issue → Linear task: Create Linear tasks from GitHub issues
Code review comments → Linear: Link review comments back to tasks
Test results → Linear: Add test failure summaries to relevant tasks
Implementation tips
Use branch naming: Enforce TASK-ID-description branch naming to make extraction easy
Start with one pattern: Implement Pattern 1 (CI failure → Linear) first, it's the highest impact
Two-way sync: Make the sync bidirectional when possible
Handle errors gracefully: If task ID isn't found, log but don't fail
These five patterns alone save an average team 1-2 hours per week in manual
syncing. That's $90-$180 per engineer per week in recovered time.
Frequently asked questions
How do I link a GitHub pull request to a Linear issue automatically?
Put the Linear issue ID in the branch name and let automation do the rest. Linear's own GitHub integration recognises a branch named like ENG-123-short-description and links the pull request to that issue automatically, moving it through states as the PR opens and merges. Branch naming is the convention that makes every other rule possible — without an ID in the branch, anything that needs to find the right issue is guessing.
Which GitHub events are worth sending to Linear?
The ones that need an owner rather than the ones that are merely interesting. CI failures on your main branch, deployment failures, and pull requests that have gone stale past your review threshold all warrant an issue because someone has to act. Pull request opened and merged events are better handled as status transitions on an existing issue than as new issues. Pushes almost never justify one.
Is the GitHub Linear integration two-way?
Linear's native integration is close to two-way for linked issues — it updates issue state from pull request activity, and can create a branch from an issue. Automation layered on top is usually one-way: GitHub events create and update Linear issues, because GitHub emits the reliable webhooks. Driving the reverse direction requires Linear as an event source and a policy for conflicts, which most teams do not need.
How do you stop automation creating duplicate Linear issues?
Trigger on state transitions rather than on a condition being true, and deduplicate on the underlying signal. The classic failure is a rule that fires whenever a label is present: editing anything on the issue re-fires the webhook and a second issue appears. Keying on the commit or pull request that caused the event, within a time window, collapses retries and repeated events into a single issue.
