guides
Debugging CI with a breakpoint instead of 40 commits
Print-statement debugging via push is the slowest loop in software. SSH into the runner instead.
Tomás Rivera · Performance engineering · 2026-02-18 · 5 min read
The standard way to debug a CI-only failure is to add an echo, push, wait eight minutes, read the log, and repeat. Teams routinely spend a day on failures that take four minutes to diagnose with a shell.
The faster loop
- Add a breakpoint step that holds the runner open on failure
- SSH in with your authorised key while the workspace is exactly as the failing step left it
- Inspect the actual filesystem, environment and tool versions rather than inferring them
- Fix, remove the breakpoint, push once
yaml
- name: Hold the runner open if the tests failed if: failure() uses: runnerhut/breakpoint@v1 with: timeout-minutes: 30What it usually turns out to be
- A tool version that differs from local
- A missing locale or timezone that only matters in date formatting tests
- Test-order dependence exposed by different parallelism
- A file the build assumed existed because it was gitignored locally
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.
Related
CI when your teammates are agentsAI coding agents push far more often than humans. Here is how that changes pipeline design and cost control.Why we publish instructions for leavingEvery migration page on this site includes the diff to migrate back off us. Here is the reasoning.What we learned running a million CI jobsQueue time, cache behaviour, right-sizing and the failure modes that only appear at scale.Stop retrying flaky testsAutomatic retries convert a real bug into an intermittent one, and train your team to distrust every failure.