Every engineering team hits a wall with CI at some point. You set things up with the best intentions: tests, automation, checks, and merge rules. But over time, it becomes less of a safety net and more of a slow-moving obstacle course.

And when it breaks — which it does — the whole team feels it. We've seen it happen. We've felt it ourselves. And yet… CI is one of the most important systems in modern engineering.

So how did something meant to help developers become something they dread?

The Emotional Cost of CI

The pain of CI isn’t just about failing builds or flaky tests. It’s deeper than that.

It’s the context-switching. The uncertainty.

The hours lost rerunning jobs that should have passed. The frustration of not knowing whether the problem is the code, the test, the infra — or just random luck. And over time, that frustration adds up. People start avoiding Friday merges. They lose trust in the pipeline. They stop believing CI is helping them move faster — even though that’s exactly what it was designed for.

We’ve all said it out loud at some point:

“CI sucks.”

We've Been There, Too

We run Mergify — a company literally building CI tooling.

And yet a few months ago, one of our own end-to-end tests started flaking. It passed locally. It passed on some CI runs. But every few days? Red. No reason. No warning. No clue. It broke our merge queue, blocked releases, and wasted hours of team time.

So yes — even we have CI scars. And maybe that’s why we care so much.

When CI breaks, it doesn’t just slow you down: it erodes confidence quietly. It steals time from developers, invisibly.

And no one's really responsible for fixing it.

CI Is a System Without Observability

The real problem? CI is a black box.

We treat it like a yes/no machine. Code goes in, checkmarks come out. But what's missing is visibility, insight, and leverage.

Ask any engineer:

• Which of your tests are flaky?

• Which jobs are most costly to retry?

• What percent of failed pipelines are false negatives?

Most can't answer. And when you can't see what's going wrong, you can't improve it.

So teams start treating CI like an unpredictable external force — not a system they can tune. Eventually, some orgs spin up entire platform teams just to handle the chaos.

But now CI is siloed, and developers feel even further from the tools meant to help them ship.

CI Is Like Going for a Run

Here's how I think about it.

CI is like going for a run. You know it's good for you, and you want to do it. But when it's raining, your legs are sore, and you're not seeing results, it's easy to skip.

That's how developers feel about CI: we all know it's the right thing in the long term, but in the short term, it's uncomfortable. It's slower. It asks for discipline. It breaks when you least expect it.

And yet… It's still worth it. That's why we don't want to throw CI away.

We want to help people fall in love with it again.

What We're Building Instead

That's where our new product, CI Insights, comes in. We didn't build it to give you another dashboard.

We built it to give you clarity.

• See which tests are flaky — and which aren't.

• Understand which jobs are failing and why.

• Automatically retry the right failures — and track what gets retried most.

• Notify the right people in Slack — before the broken PR lands on main.

• Allow you to require CI to pass before merging.

• And queue your merges to prevent drift and post-merge failures.

CI Insights is what we wanted when we hit our own CI wall. It's the observability layer CI never had.

Let's Make CI Better, Together

CI isn't the enemy. It's just invisible. And under-loved.

But we believe it can be better, and we're building the tools to help make that happen. Our hope is that more teams start treating CI not as a blocker but as a craft.

Something you tune. Something you trust. Something that helps you ship faster because it's reliable, not despite it.

If you've felt the pain, you're not alone. We're in it with you.

And if you're curious what a better CI might look like — we'd love to show you.