Merge Queue at Scale: How Headway Ships 1,000+ PRs a Week with Aviator
November 11, 2026
- Team Size
- 200+
- Structure
- Monorepo
- CI Runtime
- /
- Deploys
- Continuous
- Featured integration
- MergeQueue
Cameron Brill
Senior Software Engineer
AI tools had Headway’s engineers shipping far more code, and GitHub’s single-lane merge queue couldn’t keep up. Switching to Aviator took them from 600–800 to over 1,000 merged PRs a week, while median time in queue dropped from 48 to 30 minutes.
Impact
With Aviator, Headway's merge queue got faster even as it took on more work: time in queue dropped while weekly PR volume grew from about 600 to about 1,000.
- 600–800 → 1,000+ PRs merged per week. Even in the first week, with some cutover bumps, Headway merged almost 1,000 PRs, its highest weekly total on record. A month later it was consistently above 1,000, and the number keeps growing.
- Median time in queue: 48 → 30 minutes (down 37%).
- P90 time in queue: 75 → 60 minutes (down 20%).
Cameron Brill
Senior Software Engineer
The first week we onboarded Aviator, we merged more than any other week we'd observed. A month later, we were merging more than a 1,000 PRs a week, and that number has continued to grow.
Challenge
Headway was running GitHub's native merge queue: a single first-in, first-out lane. Every PR waited its turn, so a docs-only change sat behind backend changes running heavy test suites and CI workflows.
The first warning sign was a main branch that kept breaking. Static analysis checks failed on main because of semantic merge conflicts: PRs that merged cleanly on their own but together created conflicting sources of truth for types in the codebase.
It's not an actual merge conflict. That's what really got me thinking about merge queues in the first place.
Then AI changed the math. A few months into the AI coding boom, Headway was hiring fast and every engineer was producing far more code and pull requests. The team started hitting a ceiling on how many PRs it could merge in a day.
Cameron Brill
Senior Software Engineer
With AI getting really good, every one of our engineers was producing a lot more code and pull requests. We started hitting limits on how many PRs we could actually merge every day. That was really limiting our ability to ship, and people would just get stuck waiting on GitHub's merge queue
Why Aviator
Cameron researched every merge queue that could work with GitHub, open source and commercial, and built a feature matrix to compare them. Aviator covered most of what Headway needed and had stronger documentation than tools with similar feature sets. Proven scale mattered too: the team looked at which vendors already supported companies with very high PR throughput.
Aviator's team was also a deciding factor.
Cameron Brill
Senior Software Engineer
The responsiveness of the team was a big green flag. You were very helpful in setting up the merge queue to fit our needs and our CI.
Who should use Aviator
For Cameron, the answer is any team where merging, not writing code, has become the bottleneck.
Cameron Brill
Senior Software Engineer
I'd recommend Aviator to companies where PR throughput is a bottleneck for shipping. If you work in a monorepo with many engineers trying to merge code into the same repo and you're not using a merge queue, you should be. And I'd recommend Aviator.