Back to blog

Every engineering team has a version of the same story.

The build is slow. It used to take twelve minutes. Now it takes forty-five. Nobody knows exactly when that happened, which job is responsible, or whether it will get worse. The GitHub Actions UI shows job durations — a flat list of numbers — and nothing else. You poke at a few suspects, maybe add some timing logs, maybe rerun a job to see if it reproduces. Eventually you move on, because there's actual product work to do.

This is the default state of CI for most teams. The pipeline runs constantly, costs real money, blocks real deploys — and is essentially a black box.

The problem is observability, not effort

This isn't a problem of engineers not caring about CI performance. Most engineers care a lot. The problem is that CI pipelines have never had the same observability investment that production systems get.

If your API is slow, you have traces. You can drill from a slow endpoint to the exact database query that caused it, see CPU and memory on the host, correlate a spike in latency with a deploy. Years of tooling — Datadog, Honeycomb, Grafana, OpenTelemetry — have made production debugging genuinely tractable.

If your CI is slow, you get a number. Maybe a flame graph if you're doing something exotic. That's roughly it.

The gap is striking. CI often runs hundreds of times a day. It sits in every engineer's critical path. And yet the signal you get back is almost nothing: pass/fail, job duration, maybe some raw logs if you dig.

What we actually wanted

We wanted to look at a slow build the same way we'd look at a slow API request.

Give me a trace. Show me the spans for each job, with timing and attributes. Let me see which step added twelve minutes and what was happening on the runner when it did. Show me CPU and memory over time — not just the peak, but the shape of it. Tell me if this run was slower than last week, and by how much.

None of that requires anything exotic. OpenTelemetry already defines the right data model. The hard part was getting it out of CI runners automatically, at every job, without requiring teams to change their YAML or add custom actions.

How Rewire works

Rewire instruments your CI runs using OpenTelemetry. Connect GitHub via OAuth and your workflow runs and jobs start syncing immediately — no YAML changes, no custom actions. For teams on other CI systems, we expose a standard OTLP endpoint so you can send data from CircleCI, Buildkite, Jenkins, or anything else.

Once data is flowing, each run gets:

• Distributed traces correlated by run ID. Drill from a slow workflow down to the job, down to the step, and see exactly what happened.
• Resource metrics per job — CPU, memory, disk I/O, network, over the full duration of the run. See which step spiked, when, and by how much.
• Historical trends so you can see whether your pipelines are getting slower week over week and catch regressions before they compound.

The data lives in your account, scoped to your organization. We don't aggregate across tenants, and we don't use your CI data for anything except showing it back to you.

Why now

OpenTelemetry has reached the point where building on top of it is genuinely practical. The data model is stable, the collector ecosystem is mature, and most CI runners expose the host metrics we need. A few years ago, assembling this would have been a significant research project. Today it's mostly plumbing.

At the same time, CI costs have gotten hard to ignore. Cloud runner costs scale with build minutes, and build minutes are growing faster than most teams expect. Slow CI isn't just an annoyance — at some point it's a line item that needs justification. Observability is how you justify it, and it's how you fix it.

There's a third factor that feels more urgent to us than either of those: the volume of code moving through CI is accelerating. AI coding tools have made it genuinely easy to produce large amounts of code quickly, and the teams adopting them aren't cutting corners on quality — they're leaning harder on tests and CI as the safety net. That's the right call. But it means CI is now running more often, on larger diffs, with higher stakes if it's flaky or slow. A 45-minute pipeline that blocked one human developer now blocks an agent that could otherwise be iterating. The feedback loop matters more, not less, when code is being written faster than any human could review in real time. CI is becoming the last reliable quality gate — and a black box is exactly the wrong thing to have in that position.

What's next

GitHub Actions is the starting point because that's where most teams are. Native integrations for other platforms are in progress. We're also working on alerting — so you get notified when a workflow crosses a threshold, not just when it fails.

If you're running GitHub Actions and want to see what's actually happening in your builds, connect your repos and take a look. The first thing most people notice is a job they never knew was the bottleneck.