Live today: crashes, upgrades, failing CI, failed deploys
An autonomous maintenance department for your software.
bugstack picks up the errors your team hasn't got to, finds the cause, and proves the fix in an isolated sandbox before it opens a pull request. A teammate whose whole job is upkeep.
First on SWT-Bench Verified, 91.5% (Nov 2026). See what shipped this week.
An animation in ten scenes. A new feature ships with tests, types and review passing, and another page starts crashing. The crash reaches bugstack from any telemetry source and is grouped into one problem. The coordinator assigns the fixer and the tester. In an isolated sandbox, the tester writes a test that reproduces the failure: only orders with the new status crash. The fixer finds that the cause is a deliberate change in another file, so it updates the page that fell behind and leaves the feature alone. Back in the sandbox, the test passes with the fix and the rest of the test suite stays green. The pull request waits for review, or merges on autopilot. The view then zooms out: in one benchmark run bugstack worked through 158 problems, reaching the right action for failed deploys, security findings, dependencies and failing CI 100% of the time and for crashes 85%. On a later held-out exam of planted bugs, 43 of 44 proposed fixes held.
Fix: Add missing "returned" status label to fix undefined lookup crash
What happened
GET /api/bench/fulfillment returned a 500 (TypeError: Cannot read properties of undefined, reading 'toUpperCase') instead of the fulfillment board rows.
Why it broke
fulfillment/route.ts:23 reads STATUS_LABEL[o.status]!.toUpperCase(); order ord_3003 in orders.ts has status "returned", which isn't a key in STATUS_LABEL, so the lookup is undefined and the ! assertion doesn't stop the crash.
Risk
Low; this only adds a missing map entry, but if new statuses are added later without a matching label the same crash could recur.
- ✓ 4 of 4 checks passed
- ✓ 1 file changed, +1 −1
- ✓ Merged by a person, 12 minutes after it opened
The fix is a real pull request: number 77, which bugstack opened on our own repository on 11 September 2026 for a defect we planted as a test. The totals are from our internal benchmark of 25 September 2026, and the held fixes from our held-out exam of 8 October 2026. The 30 minutes is our own estimate for a routine fix.
Every team has a crash nobody has picked up in three weeks.
Without bugstack
Each item takes hours to investigate, so the pile only grows.
With bugstack
bugstack works through the pile on its own, and your team reviews finished fixes.
bugstack takes the parts it can prove: crashes it can reproduce and upgrades that pass your checks.
Developers spend 17 of every 41 working hours on maintenance, according to Stripe’s 2018 survey. With bugstack, your team’s part is reviewing the finished pull requests.
A pull request opens only when its test fails before the fix and passes after.
bugstack copies your repository into an isolated sandbox and writes a test that reproduces the bug. The test has to fail on your current code, for the bug’s own reason. Then the fix goes in: the same test has to pass, and the rest of your test suite has to stay green.
The test must fail with the bug’s own error
A test that fails for anything else, a typo or a bad import, never counts.
The sandbox has no network and none of your secrets
Dependencies install from the package registries, then the network is cut before the first test runs. bugstack’s keys never go in, and the sandbox is destroyed when the fix is done.
The pull request includes the test
The proof travels with the fix, so the bug stays fixed. Your own CI runs on it too.
We put the test step on a public benchmark. SWT-Bench Verified gives an agent 433 real GitHub issues and asks for a test that fails on the broken code and passes once the issue is fixed, the same bar the sandbox sets. bugstack’s tester did it for 91.5% of them, the top score on the leaderboard on 1 November 2026. See the result
Review it like a colleague's work.
Ask a question or request a change on bugstack's pull request. With replies switched on for the repository, it answers in the thread and pushes the change.
One pull request per problem
It updates the one it opened instead of piling on new ones.
Your edits come first
If someone on your team has changed its pull request, it never overwrites them.
It follows up
If the bug keeps happening while the fix waits, it tells you on the pull request.
Upgrades and security patches, kept current.
One pull request per package, with the lockfile rebuilt and your checks passing. When a newer version ships, bugstack updates the same pull request. Upgrade pull requests are for npm today; PyPI, RubyGems and Go packages are scanned and reported.
You decide how much it does on its own.
Every bug fix is proven in the sandbox, and every change has to pass your checks. Then your setting decides: wait for your OK, or merge on its own. Changes to security code always wait for you.
Suggest. bugstack writes the fix and waits. Nothing opens until you say go. Review, where most teams start. bugstack opens the pull request. You merge it. Autopilot. bugstack merges a fix on its own once the sandbox has proven it and your checks pass. Set per repository.
Scope
See exactly what bugstack can fix today, and what it can't.
Fixes on its own
On Autopilot: crashes, package upgrades, failing CI, failed deploys.
Asks you first
Big changes, changes to security code, and judgement calls.
Not yet
Silent bugs, browser errors and slowdowns. On the way.
- Errors your server code throws and doesn't catch
- Null and undefined access, missing imports, unhandled async failures
- Python NoneType, Ruby nil and Go nil-pointer crashes
- Deploys that fail on a connected host (Render today)
- A failing CI run on your default branch
- Out-of-date npm packages, checked daily (PyPI, RubyGems and Go are scanned and reported)
- Logic errors that throw, where the right behavior depends on what you intended
- Failures at the edge of an outside service (bugstack can guard the call, it can't fix their API)
- Any fix over 3 files or 30 lines, or one that touches auth or security code, however confident the model is
- Dependency upgrades that change behavior
- Packages with known vulnerabilities, checked every four hours: the upgrade is prepared, and on Autopilot it can merge once your CI passes
- Secrets committed to the repository, scanned nightly: bugstack tells you, and never rotates a secret itself
- A wrong answer that comes back as a success
- Anything that fails without throwing, like a job that quietly stops
- Performance regressions
- Errors in your users' browsers
- Failed deploys on hosts other than Render
- Repositories outside GitHub
bugstack is under active construction. This is the honest edge of what it does today. bugstack maintains software, it does not build new features. See how each kind of fix works →
How well it works, measured.
How the tester ranks on a public benchmark, how the fixer did on bugs we planted in our own code, and what it costs. Every number is dated.
On a public benchmark, scored independently
of real GitHub issues reproduced with a test that fails before the fix and passes after. First on SWT-Bench Verified.
- bugstack Sonnet 5.5, Opus 5.5 picks the test91.5%
- Claude Code Opus 5.5, next on the leaderboard87.8%
- Claude Code Sonnet 5.5, the model bugstack writes with75.8%
SWT-Bench gives an agent 433 real issues from 12 open-source Python projects. For each one it has to write a test that fails on the broken code and passes once the issue is fixed. The benchmark scores the tester: the step that proves a bug before bugstack fixes it. The fixer has its own exam, below.
SWT-Bench Verified, unit test mode, 433 issues. bugstack: Claude Sonnet 5.5, with Opus 5.5 choosing between candidate tests. Scored by the SWT-Bench maintainers, 1 Nov 2026. How we ran it
On our own code, planted bugs
of the fixes it proposed held: 43 of 44 on an exam of planted bugs, sealed before we tuned the fixer.
245 of 252 on the full set of planted bugs, in TypeScript, Python, Go and Ruby.
Held means the error is gone, the response matches the healthy one, and types and tests pass. Exam 8 Oct 2026, full set 14 Oct 2026, three passes per bug, machine-graded.
What it costs
includes $100 of usage credit every month, plus a one-time $100 welcome bonus when you start.
of credit to diagnose and fix a typical crash.
Internal benchmark, 25 Sep 2026
Use our SDK or the error tracking you already run.
Add two lines to your app, with your key and bugstack's endpoint, and bugstack sees every crash as it happens. Already use Sentry or Datadog? We set it up with you.
Built-in SDKs
JavaScript, Python, Go and Ruby. Express, Next.js, Flask, FastAPI, Django, Rails.
Or your existing tools
Sentry, Datadog, or your own source.
Plus your code and deploys
Packages and secrets scanned in GitHub. Failed deploys from Render.
See bugstack work on your own code.
Book 15 minutes with the founder. Bring a repository and your questions.
Prefer to try it yourself? Get started: $100 a month, with a $100 welcome bonus when you start.