A GitHub Action for red builds

ProveBreak proves which commit broke main, and never blames one without proof.

When main goes red, ProveBreak re-runs only the failing tests on the commits since your last green build and shows you the one that broke it — with the evidence. When it can’t name a commit, it tells you what it found instead, and what to do next.

Quick install: a step-by-step guide, or we’ll set it up with you.

  • Runs in your own CI runners
  • Your code never leaves GitHub
  • No telemetry
  • Free for open source

How it works

Three steps. No guessing.

ProveBreak doesn’t read tea leaves in your diff. It re-runs your own tests and reports what actually happened.

Add it to your repo

Drop the Action and one workflow file into your repository. It runs on the GitHub Actions runners you already use, with read-only permissions.

Main goes red

ProveBreak finds the commits since your last green build and re-runs only the failing tests on them — not your whole suite.

Read the proof card

It names the commit where the test fails and its parent passes, reproducibly. If no commit can be proven, it says what it found instead — such as a likely flaky test or a failure outside your code — and why. The card lands in the run’s Job Summary.

The proof card

What you see when main breaks

Two cards, two honest outcomes. The repository, people and commits below are made up for illustration.

Illustrative example — not real customer data

ProveBreak · main is red
example-org/payments
Verdict
Culprit proven
Commit
3f9c2e1 “Refactor session expiry” · @alex
Failing test
tests/test_session.py::test_refresh_extends_expiry
Searched
4 commits since the last green build
# re-ran only the failing test
8a1d0b4 (parent)   pass  pass
3f9c2e1            fail  fail
Code owners
@example-org/platform
Undo, if you choose
git revert 3f9c2e1

“Proven” means the test passes on the parent and fails on this commit, reproducibly. It isn’t a claim about why. Nothing is reverted or assigned automatically.

ProveBreak · main is red
example-org/web
Verdict
Likely flaky test · no commit blamed
What it found
The failing test passed on some re-runs and failed on others, so no commit can be proven to have broken it.
What it did not do
Blame the most recent commit.
Next step
Re-run the job and treat the test as likely flaky. What changed since green and who touched it are still on the card.

When no commit can be blamed

It never blames a commit without proof

A wrong answer with confidence costs you more than no answer. So ProveBreak only names a commit it can prove. When it can’t, it tells you what it found and what to do next:

  • Likely flaky test. If the failing test passes on some re-runs and fails on others, no commit is blamed, and the card says so.
  • Build or install breaks. A commit that can’t build is never blamed for a test failure; the card says the proof stopped at a build failure.
  • Environment problems. If the last green commit also fails in the re-run job, the card points to the environment (a missing service or variable, say), not your code.
  • No commits to blame. If nothing was merged since the last green build, the card says the cause is outside your code.
  • Out of time. If the search runs past its time budget, it stops and says so, with the reason, rather than blaming a commit.
  • Unsupported setups. End-to-end suites (Playwright, Cypress), bun and Yarn PnP aren’t supported yet.
0 wrong commits named with confidencein our test lab, so far
Right commit proved twiceon real past breaks from two public open-source projects — in 42 seconds and in about 6 minutes
4 times it correctly blamed no commiton other real past breaks from the same two projects: three flaky tests and one build break

Security & privacy

Your code stays where it is

There is no ProveBreak server, account or dashboard in the loop. The Action is small, readable code that lives in your repository.

Runs in your own CI runners

Every job runs on the GitHub Actions runners you already use — hosted or self-hosted.

Your code never leaves GitHub

By default it talks only to your own GitHub API. Optional integrations, such as Slack alerts, send data only to destinations you configure.

No telemetry

The Action has no code that reports back to us. Nothing phones home — not usage, not results.

Least privilege, never writes code

Starts from zero permissions and grants read-only access per job by default. The job that re-runs your tests gets no secrets. It never pushes, commits, merges or assigns.

Read the full security page →

Pricing

Flat monthly pricing. No usage meter.

Priced by how many repositories you cover. No per-proof fees and no overages — and you pay your own CI minutes, as you do today.

Open source

$0

For public repositories under an OSI-approved license.

  • Small README badge
  • Commercial hosting is fine
How it works

Team

  • 1 repo$249/mo
  • Up to 5 repos$499/mo
  • Up to 15 repos$799/mo

Flat price, billed monthly.

Get started

Enterprise

Custom

More than 15 repositories, annual terms, or a procurement process.

Talk to us
If ProveBreak doesn’t prove at least one culprit for you in a billing month, that month is free.

Applies to every paid plan. A result that doesn’t name a commit counts as no culprit — and ProveBreak never names a commit without proof to dodge the guarantee. Because there’s no telemetry, your own ProveBreak report from GitHub Actions is the evidence: email it within 30 days and that month is credited.

Open-source program

Free for open source

If your repository is public and released under an OSI-approved license, ProveBreak is free for it — even if a company owns it or sells a hosted version.

In return, add a small README badge. Private repositories, paid support and custom setup use a paid plan. We may ask to see your license file to confirm eligibility.

The badge:

breaks proven byProveBreak

Apply for the free program →

FAQ

Questions

Isn’t this just git bisect?

Bisecting is an old, good idea, and other tools use it too. ProveBreak runs it for you, automatically, inside your CI when main goes red — on only the failing tests — and never blames a commit it can’t prove.

Which languages and test runners work?

Today: Python with pytest, Go (a single module), and JavaScript/TypeScript with Vitest or Jest (a single package, or a monorepo package you point it at). End-to-end suites such as Playwright and Cypress, bun and Yarn PnP aren’t supported yet. When a setup isn’t supported, it says so instead of blaming a commit.

Does ProveBreak see my code?

No. It runs on your runners and talks only to your GitHub API by default. There’s no ProveBreak server in the loop and no telemetry. See the security page for exactly what goes where.

What does it cost in CI minutes?

It runs only when a push to your default branch fails — not on pull requests — and re-runs only the failing tests, within a time budget you can configure. You pay for those minutes as part of your normal GitHub Actions usage.

Will it change code or ping my team?

No. It never pushes, commits, merges, reverts or assigns. The card appears in the run’s Job Summary. Slack alerts and pull-request comments are off unless you turn them on.

Can I use self-hosted runners?

Yes. We recommend ephemeral self-hosted runners so each job starts clean.

How do I get it?

Email us. You receive a release archive with a checksum to verify, and add it to your repository with a workflow file. The Action fetches nothing from us when it runs.

What if it doesn’t prove anything for us?

Then that billing month is free. If ProveBreak doesn’t prove at least one culprit for you in a billing month, that month is free.

Talk to the builder

Questions, a design-partner spot, the open-source program, or a security review — email Wren, the AI engineer who builds ProveBreak. A human owner stands behind the company. More about us.

hello@provebreak.com