Linear, the project management tool, has posted an engineering post titled “CI costs are high,” and the title is accurate: the company explains how it reduced its continuous integration wait time from more than 6 minutes to just over 5, while also halving runner time per test. The piece is a masterclass in performance optimization, and it is worth reading for anyone who has seen CI pipelines slow down as their codebase grew.
The issue was straightforward. Linear’s developers were putting code into production faster than the system could check it for mistakes. Pull requests still had to pass through CI, but as development sped up, the pipeline started to slow down, becoming a bottleneck. That pushed infrastructure costs up and left agents waiting longer for feedback, which is the opposite of what CI is supposed to do.
The Four Paths to Faster CI
Four distinct approaches were tried, each one broken down with specific figures in the post, as Linear’s engineers pushed forward on all sides.
- Upgrading infrastructure and tooling
- Optimizing the jobs that gate other work
- Reducing repeated setup
- Making test execution more efficient
The most interesting items are the first two, since they require actual system changes rather than merely adjusting code. The final two are more about refactoring and process, but they still made a difference.
Upgrading the Machines
Linear saw its early gains by removing its CI workloads from GitHub Actions and moving them onto third-party runners that offered faster CPUs, higher-performance storage, and improved cache infrastructure. A like-for-like comparison of the two days before and after the switch showed that jobs ran 34% faster on average. Some workloads, like tsc, saw declines in duration of 52%.
That is the kind of victory that happens when you stop renting someone else’s slow machines and buy your own. It demanded almost no tuning of CI itself, which is a rare thing.
The Compiler Swap That Moved the Bottleneck
The compiler switch came next. Linear moved to tsgo, the native TypeScript compiler, and that move cut the weekly median of the tsc check by 73%. The reduction was large enough to move the bottleneck entirely off of typechecking.
It really does feel like magic when you change one tool and the pipeline stops being slowed down by a step that once took most of its time. The post makes no effort to soften the scale of the change — 73% is not a small adjustment, it is a complete transformation.
“Fetch only what each job needs”
Linting Without the Type Checker
Fixing the memory problem with linting was another early goal. Several of Linear’s custom lint rules relied on TypeScript type information, whether to enforce a restriction or apply an autofix. So every lint run had to build the full type graph before evaluating those rules, and that made linting one of the most memory-intensive CI jobs.
ESLint eliminated TypeScript after Linear used static analysis on the abstract syntax tree to spot function-like structures and guard patterns without requiring type information. That approach cut API lint time by 68%, reduced full-repository lint time by 55%, and brought down memory usage substantially.
The moment of payoff arrived after Linear switched to Oxlint, which cut the CI runner-minutes consumed by linting.
Fixing the Checkout Hang
The best part of the story is the checkout fix. After Linear changed the system it runs on, the company found that checking out code was taking longer and would occasionally hang. Since third-party runners live outside GitHub’s network, they depend on a direct IP link to reach GitHub. That link was the source of the hangs, per the provider’s findings.
Several of Linear’s workflows begin with a checkout, so a stalled fetch could delay the entire CI run. Linear’s response was to replace actions/checkout with a composite action of its own that retried with backoff, and set GIT_HTTP_LOW_SPEED_LIMIT and GIT_HTTP_LOW_SPEED_TIME so a stalled connection aborts after about 30 seconds instead of hanging. It also used the checkout cache, which keeps a persistent git mirror on a sticky disk.
Fewer runs saw a critical-path job sitting idle while checkout took its time finishing.
The Merge Queue Fix
Linear spotted jobs on the critical path that weren’t necessary. The company was writing cache markers as part of the final check before merging, meaning a pull request could linger in the merge queue even after its tests had passed. Shifting that write into a job that runs after the test shards finish but doesn’t block anything cut 42 seconds from the merge path for every API pull request and merge-queue entry.
The combined adjustments cut the API pull request check time on cache misses by roughly a minute, and they also lowered the number of runner starts.
What This Means for You
Anyone who builds CI pipelines should read this story, since the problems Linear faced are universal. CI bottlenecks arise when pipelines take a long time to begin, a long time to run, and a long time to fail. Linear targeted each of those dimensions, and the outcomes are tangible.
CI performance is a system issue, not a code issue. It doesn’t matter how quickly your tests run if your pipeline spends half its time starting a runner or pulling down a repository — the tests amount to nothing. The actual task is locating where the time is being spent and removing it.
Linear moved with care and deliberation. It measured the ground first, it gave the problem a name, and it went after it from several directions at once. The post is open about what succeeded and what failed, and it gives the impression of a team that truly wanted to address the issue rather than simply put out a blog post.
The story shows that performance optimization does not spring from magic. It is built from a long chain of small, gradual changes that eventually turn into a large result. Linear’s CI pipeline is now quicker and costs less, and the company devoted a few months to reaching that point.
This post offers a look at the friction that piles up in a pipeline as a codebase expands, and it demonstrates what happens when you measure those friction points and address them one after another. If you are putting together CI for a growing codebase, it is worth your time.
High CI costs did not happen by accident; they were allowed to accumulate. Linear did not accept that path. Instead, it measured, optimized, and published its results, showing that the right way to handle engineering is through measurement and transparency rather than acceptance.
Source material: “AI coding has made CI a bottleneck, so we reworked ours to keep up,” linear.app.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.