Compare
Good question. ci-snitch is real and free, so we ran it against a repo we already
know cold, webpack/webpack, in the same 30-day window we'd already measured, and
compared the two reports line by line. Here's exactly where they agree, and where one of them
stops.
ci-snitch pulls a repo's real GitHub Actions history and turns it into a genuinely solid
telemetry report: per-job p50/p95 durations, statistically flagged changepoints pinned to a
commit SHA, p99 outliers, failure rates, billable-minute cost, and step-level timing. On
webpack/webpack it read the Github Actions workflow's 30-day median
wall-clock at 48m16s across 219 runs. Our own independent baseline, ten
interleaved live runs sampled 2026-07-21 inside that same window, read
45m57s. Those two numbers, collected two completely different ways, agree
within about 5%. We're not disputing what ci-snitch measures.
Where the two reports diverge
| ci-snitch | greenmerge | |
|---|---|---|
| Where is the time going? | Yes: p50/p95, changepoints, outliers | Yes: critical-path model |
| Proposes a specific structural fix | No | Yes: a composed, named diff |
| Runs the fix and measures the real result | No | Yes: interleaved A/B on your CI |
| Will guarantee a number | No mechanism for this | Yes: the measured floor |
| Failure/flake-rate detection | Yes | Not yet in our free scan |
That last
row isn't spin: ci-snitch flagged webpack's own Github Actions workflow at 39%
failures, "flaky, worsening." Our free scan doesn't compute that today. It's a real gap, and
it's on our list.
ci-snitch's one suggestion aimed at wall-clock is "use a bigger runner." That's a spend lever, not a structural one: more cores costs more per minute, and it doesn't touch your CI's actual dependency graph. Its own report doesn't verify whether that spend would even move your critical path; it's a hint, not a modeled or measured number. Nothing in the report proposes restructuring the pipeline itself.
Our engine originally modeled a +45.6% win for webpack from two composed changes. We ran it for real: ten interleaved runs on GitHub-hosted CI, the substrate a client actually uses. It came back +14.1%, statistically significant but a third of the model's number. Read the full case study → If we don't ship our own number until it's measured, we're not going to ask you to trust ci-snitch's unmeasured runner-sizing hint, or anyone else's.
If you're already running ci-snitch or something like it, bring the report. It's a genuinely useful starting point. We'll tell you, for free, which of its findings are worth turning into a measured, guaranteed number.
Book an engagement