Find bugs and vulns code review misses

Code review reads the diff. Heal runs your product, in a sandbox that replicates production, and hunts for reproducible bugs, runtime vulnerabilities and performance issues. Each one comes with the failing test that proves it.

Free trial · no credit card required

“Found bugs our code review missed.”

Twenty, on X

Code review reads the diff. Heal runs the product.

Keep your code reviewer: it reads every pull request. Run heal on the whole product, weekly or before a release, and it hands back what a diff can't show, each defect with the failing test that proves it.

  • What it sees

    The diff of one pull request. A bug between untouched code, config, data and a third-party service is outside it.

    The running product: every feature, its data and the services it calls, changed or not.

  • Is it real?

    Flags a pattern that looks wrong. Whether it can be reached, and what happens when it is, is left to you.

    Proves it: a test fails twice, then fails again when heal re-runs it itself. What it cannot reproduce, it does not file.

  • What you get

    Comments on lines of code.

    A defect with its steps, the captures, and the failing test that turns green once it is fixed.

  • Security

    Matches code that looks like a vulnerability.

    Fires the real exploit at the sandbox, signed in as two people, and reports what came back.

  • Payments, mail, third-party APIs

    Sees the call in the code, never what the service answers.

    Mocks or emulates them in the sandbox, then replays them failing, slow, or answering twice.

See heal run on open-source repos.

Heal built a production-like environment for each repo and uses it to find and validate reproducible defects.

Free for open source.Message @healdevHQ and get free credits to get rid of bugs on your project.

Sandbox your app and find runtime issues

Heal learns how to run your environment and mocks what cannot run. It reads your code for suspicions, like a reviewer would, then runs each one against the sandbox: only what a test reproduces is filed.

Reads your code, maps your architecture.

Features6 features, 29 screens
  • checkout6 screensroutes/checkout.tsx:44
  • billing4 screensfeatures/billing/plans.tsx:12
  • search3 screensfeatures/search/index.ts:8
  • onboarding5 screensroutes/start/[step].tsx:21
  • account4 screensroutes/account.tsx:30
  • admin7 screensapps/admin/src/main.tsx:5

What E2E tests and scanners miss

Untested integrations, edge cases, services disabled in staging, hard-to-mock async services. And everything where you need a runtime.

Heal runs these, on the sandbox:

  • schemathesis
  • ZAP
  • dalfox
  • jwt_tool
  • nuclei
  • semgrep
  • trufflehog
  • sqlmap
  • and more…
  • Edge cases

    E2E runs the happy path against staging. Requests that fail, slow down or come back with a field missing are never staged.

    Walks every flow again with the world failing, and files the screen that says “nothing here” when the server broke.

  • Services turned off in staging

    Payments, mail and third-party calls are switched off.

    Mocks them in a production-like sandbox, so the flows behind them run for real.

  • Validated runtime security issues

    A static scanner reports a pattern in code that may never be reachable, and cannot tell you if it is.

    Fires the real exploit at the sandbox, signed in as two people, and reports only what a test reproduces.

  • Missing routes

    Dead pages, assets that do not load and screens no feature names are nobody’s test.

    Crawls every link once, over the whole running app.

Point it at your repo.

Connect GitHub and get your report. It runs locally or in the cloud.

Free trial · no credit card required

SOC 2 certified · trust.heal.dev