Ready to give it a try?

📺 Watch the demo: youtu.be/ORE30UUvOJk
🚀 Vote on Product Hunt: www.producthunt.com/products/tru...
🌐 Learn more: trunk.io/flaky-tests
📖 Get started: docs.trunk.io/flaky-tests

✅ Works with any language and CI provider
✅ Quarantines flaky tests on CI
✅ Keeps your team shipping instead of debugging random failures

We're live on @ProductHunt today - every upvote helps us reach more frustrated developers!

🔗 www.producthunt.com/products/tru...

The problem: You push code, CI fails on some unrelated test, you rerun it and it passes. Sound familiar?

The solution: Automatically detect and quarantine flaky tests so they can't block your team's progress.

The math is simple:
- Spending $3K+ monthly on CI?
- Have 20+ engineers?
- 30+ PRs per day?

Trunk pays for itself in CI savings alone.

📊 Read More: trunk.io/blog/outgrow...
🚀 Learn more about Trunk Merge Queue: trunk.io/merge-queue

5/5

Real customer example:
- Team of 50 engineers
- Was spending: $15K/month on CI
- After Trunk: $4K/month on CI
- Savings: $11K/month vs $500 Trunk cost

ROI: 22x in CI costs alone (not counting dev productivity gains)

4/5

Trunk's batching approach:
- Batch [PR1 + PR2 + PR3]: 10 min test ⏱️

Total: 10 minutes, 1 CI run
Cost savings: 70% reduction

If batch fails? Smart bisection finds the culprit automatically.

3/5

Traditional merge queue approach:
- PR 1: 10 min test ⏱️
- PR 2: 10 min test ⏱️
- PR 3: 10 min test ⏱️

Total: 30 minutes, 3 CI runs
Cost: $$$ for each individual test

This doesn't scale.

2/5

The result:
✅ Teams don't block each other
✅ Fast changes merge in minutes, not hours
✅ Complex changes get proper validation
✅ Monorepo becomes productivity multiplier again

Stop fighting your architecture. Make it work for you.

📖 trunk.io/blog/outgrow...

4/4

Trunk's solution: Parallel queues

📝 Docs queue: 2 min → merge ✅
🔧 Backend queue: 45 min → merge ✅
🎨 Frontend queue: 15 min → merge ✅

All run simultaneously.
Teams work independently again.

3/4

Classic monorepo problem:
📝 Docs team: 2-min PR stuck behind...
🔧 Backend team: 45-min database migration
🎨 Frontend team: 15-min feature addition

Everyone waits for the slowest PR.
Independent teams blocked by unrelated changes.

2/4

The numbers don't lie:
- 3-5x faster merge times
- 60-80% lower CI costs
- Near-zero main branch breakages

If you're spending too much on CI or have 20+ engineers, the ROI is obvious.

📖 Full comparison: trunk.io/blog/outgrow...

6/6

Enter Trunk Merge Queue:
🚀 Parallel queues (independent changes don't wait)
💰 Batching (90% CI cost reduction)
⚡ Optimistic merging (fast PRs don't wait for slow ones)
🔍 Full visibility and debugging

5/6

GitHub Merge Queue limitations:
- Single queue = bottlenecks
- No batching = high CI costs
- Limited visibility when things fail
- Queue jumping rebuilds EVERYTHING

For small teams? Fine.
For 50+ engineers? You need something better.

4/6

GitHub's merge queue fixes this with "predictive testing":

❌ Old way: Test PR against stale main
✅ New way: Test PR against "future main" (including other PRs ahead in queue)

But GitHub's implementation has limits...

3/6

9:00 AM - Alice creates PR: renames foo() → bar()
9:05 AM - Bob creates PR: adds code calling foo()

Both PRs test against OLD main branch.
Both PRs pass ✅
Both PRs merge.
Main branch: 💥 BROKEN

This is the "stale CI problem"

2/6