How bugstack works

A runtime error occurs in your production app. Under two minutes later, a pull request with a tested fix lands on your repo. Here’s every step in between.

The pipeline

Every error flows through a deterministic, seven-stage pipeline:

1. Capture — SDK intercepts the error at the framework level
2. Deduplicate — Fingerprint hash prevents re-processing identical errors
3. Triage — Classifier separates fixable code errors from out-of-scope issues
4. Build context — Relevant source files are fetched from your GitHub repo
5. Generate fix — Claude analyzes error + stack + context and produces a surgical diff
6. Open PR & wait for CI — Pull request is created; bugstack watches your CI checks
7. Auto-deploy (optional) — If confidence is high and CI passes, the PR can auto-merge

1. Capture

The bugstack SDK attaches to your framework’s error paths — Express error middleware, Next.js instrumentation.ts, Django middleware, Flask error handlers, Rails rescue_from, or Go recovery middleware. When an unhandled error occurs, the SDK collects:

• Error name, message, and full stack trace
• Parsed stack frames (file, function, line, column)
• Environment metadata (language version, framework, OS, SDK version)
• A fingerprint hash for deduplication

The JavaScript SDK captures full request context by default (route, method, status code, URL, query params, request body, headers). The Python, Ruby, and Go SDKs capture minimal error metadata only — no request bodies unless explicitly enabled.

All payloads pass through automatic redaction before transmission. Capture is non-blocking: it does not add latency to your request/response cycle.

2. Deduplicate

Each error is assigned a fingerprint hash based on its error type, message pattern, and stack trace. If the same fingerprint appears within the deduplication window (default: 5 minutes), the duplicate is batched with the original and not re-processed as a separate fix. This prevents a single cascading failure from generating dozens of identical pull requests.

3. Triage

A classifier evaluates each error to determine whether it is a fixable code error or an out-of-scope issue. Out-of-scope errors include:

• Infrastructure failures (DNS, network timeouts, disk full)
• Configuration errors (missing environment variables, wrong credentials)
• Dependency bugs (errors originating inside node_modules, third-party gems, or vendored packages)

Out-of-scope errors are still reported in your bugstack dashboard, but bugstack does not attempt to generate a fix for them.

4. Build codebase context

For fixable errors, bugstack pulls the relevant source files from your GitHub repository. Only the files referenced in the stack trace and their immediate dependencies are fetched — bugstack does not clone your entire repo.

File access uses your own GitHub token, which is encrypted at rest with AES-256-GCM. Per-user isolation ensures that tokens are never shared across accounts.

5. Generate fix

The error payload, stack trace, and retrieved source files are sent to Anthropic Claude. Claude analyzes the root cause and produces a minimal, surgical diff — changing only what is necessary to resolve the error without altering unrelated behavior.

The generated fix targets the exact failure mode observed in production: null checks for null-access errors, missing imports for import failures, type guards for type mismatches, and so on.

6. Open PR and wait for CI

bugstack creates a new branch on your repository and opens a pull request with:

• A clear title describing the error and fix
• A detailed description with the error message, stack trace, and explanation of the change
• The minimal diff produced in the previous step

Once the PR is open, bugstack monitors your CI pipeline (GitHub Actions, CircleCI, Jenkins, or any provider that reports status checks on PRs). If CI checks fail, bugstack retries the fix using the CI failure output as additional context — often resolving test failures or lint issues on the second attempt.

7. Auto-deploy (optional)

If the fix passes CI and meets your configured confidence threshold, bugstack can auto-merge the PR. Auto-deploy is configurable per project from the dashboard and is off by default. Options include:

• Manual review — PRs are opened but never auto-merged (default)
• Auto-merge on CI pass — Merge automatically when all status checks pass
• Auto-merge with confidence threshold — Merge only when the fix confidence score exceeds your configured minimum

What bugstack does NOT do

• Does not modify code without opening a PR (unless auto-deploy is explicitly enabled)
• Does not capture user request bodies by default in Python, Ruby, and Go SDKs
• Does not store your source code on bugstack servers — files are only retrieved transiently per fix
• Does not attempt to fix infrastructure, configuration, or dependency errors
• Does not bypass your CI — every fix must pass your existing checks before merge

Next steps

• Data and privacy — exactly what the SDK sends and how data is handled
• Quickstart — install bugstack in under 5 minutes
• Security — encryption, isolation, and compliance details