engineering
Your CI pipeline is a distributed trace
Modelling workflow runs as OpenTelemetry traces makes the critical path obvious in a way that a list of step durations never does.
Tomás Rivera · Performance engineering · 2026-02-25 · 7 min read
A workflow run is a tree of jobs, each a sequence of steps, with dependencies between them and time spent waiting. That is a trace. Treating it as one changes what you can see.
The list view lies
Sorting steps by duration finds the slowest step. It does not find the bottleneck, because a fast job waiting on a slow one contributes its full wait to the total and shows up nowhere.
What to emit
- One root span per workflow run
- A child span per job, including queue time as a distinct phase
- A child span per step
- Attributes for runner label, cache hit, exit code and utilization
Once CI spans sit in the same backend as production traces, the same people who debug latency in production can debug it in CI, with the same tools.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.