ProveBreak is a small, self-funded software studio in Pennsylvania. We build developer tools and, now, private interactive 3D spaces streamed to the browser.

Our first product (paused): a GitHub Action for red builds

Evidence for red builds, without guessing.

When main goes red, ProveBreak re-runs the failing tests on your own runners and shows the evidence. When it can’t prove a culprit, it says so instead of guessing, and tells you what to do next.

What we're building now See an example proof card
  • Runs in your own CI runners
  • Your code never leaves GitHub
  • We receive only the verdict

What we're building now

Private 3D spaces, streamed to any browser.

We're prototyping invite-only, interactive 3D environments built with Unreal Engine 5 and streamed from cloud GPUs (Pixel Streaming). People join from a link in Edge or Chrome on a console, laptop or phone, with no install and no gaming PC. They walk around together with a controller and hold real meetings inside the space.

Status: research prototype

Built and demoed internally. Not open to the public, no sign-ups yet.

Privacy first

Every space is private by default, behind a login, with nothing public.

First product · 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

Add one small workflow file to your repository. It runs on the GitHub Actions runners you already use, with read-only permissions. A short setup, and we help you through it.

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 · 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 · example-org/web
Verdict
Likely flaky test · no commit named
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
Point to 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 proven

It never names a commit without proof

A wrong answer with confidence costs you more than no answer. So ProveBreak only names a commit it can prove. Verdicts point to a commit and a change, never a person. 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 named, and the card says so.
  • Build or install breaks. A commit that can’t build is never named as the cause of 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 new commits. 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 naming a commit.
  • Unsupported setups. End-to-end suites (Playwright, Cypress), bun and Yarn PnP aren’t supported yet.
Evidence with every verdictEvery verdict comes with evidence.
No guessingWhen ProveBreak can’t prove a culprit, it says so instead of guessing.
Clear next stepsEach card explains what it found and what to check next.

Security & privacy

Your code stays where it is

Your code is checked out and analyzed only on your own GitHub Actions runner. Our service only receives the verdict, never your code.

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

Your code is checked out and analyzed on your own runner and stays in GitHub. Optional integrations, such as Slack alerts, send data only to destinations you configure.

We receive only the verdict

Our service receives the repository name, commit SHAs, test names, the verdict, a short evidence summary and runner minutes. Never your code, never your secrets.

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 →

First product

Status: paused.

Our first product, a GitHub Action that re-runs failing tests and shows evidence for red builds, was built and tested in Sep–Oct 2026. We're not taking new design partners right now. Questions: hello@provebreak.com.

FAQ · first product

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 names 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 naming a commit.

Does ProveBreak see my code?

No. Your code is checked out and analyzed only on your own GitHub Actions runner. Our service only receives the verdict: the repository name, commit SHAs, test names, the verdict, a short evidence summary and runner minutes. Never your code or secrets. 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.

Talk to the builder

Questions or a security review — email us. Wren, the AI engineer who builds ProveBreak’s software, answers email and always says it’s an AI. ProveBreak is owned by Joseph Bennett. More about us.

hello@provebreak.com