Autter

Production errors, answered with pull requests.

Autter Runtime watches production through a lightweight open source SDK, folds the noise into a handful of incidents, traces each one to the deploy and the pull request that caused it, then investigates against your real code and opens the fix as a PR. You get pinged when it is ready. Nothing merges without you.

@autter/runtime-browser · node · next · open source

autter runtime · triagedemo data
  • errorTypeError: Cannot read properties of undefinedcheckout-web · cart/summary.ts:112×214
  • errorFetchError: upstream timed outpayments-api · client.ts:57×57
  • warningRangeError: invalid time valueweb-booking · slots.ts:41×12

incident #482 opened · deploy 8f3c2a1 · matches PR #482

investigating → fix PR on the way

Noise is the default state of production.

Any tool can show you ten thousand occurrences. The work is turning them into the three problems worth waking someone for. Autter fingerprints every occurrence, folds repeats into issues, and promotes an issue only when it earns it.

occurrence issue
One fingerprint per failure mode: error type, normalized message, top stack frames. Counts accumulate on the group, not in your inbox.
issue incident
A spike past the threshold, or a single fatal occurrence. Only error-level groups can promote, and warnings never page anyone.
incident critical
A fatal occurrence on an open incident escalates it instead of opening a second one. Severity is earned, not guessed.

The life of an incident.

Eight stages, run unattended from the first occurrence to the closed case. Your part starts at review and ends at merge.

  1. Detected.

    A production error crosses the wire. The SDK captures the occurrence with its stack trace, service, environment, and release, and severity is read at the door: fatal, error, warning, or info.

    02:47:31 UTC · checkout-web · productionTypeError: Cannot read properties of undefined (reading 'total')cart/summary.ts:112 · severity: error

  2. Grouped.

    A stable fingerprint built from the error type, the normalized message, and the top stack frames folds thousands of raw occurrences into one issue. Counts accumulate on the group, not in your inbox.

    fingerprint 9d41c7 · 214 occurrences · 61 sessionsfolded into one issue · threshold crossedincident #482 opened

  3. Correlated.

    When an issue is promoted to an incident, Autter walks your deployment history. A deploy that landed just before the first occurrence is matched to the merged pull request that shipped it: the suspected cause, named.

    deploy 8f3c2a1 landed 22 min before first occurrencematches merged PR #482 · cart totals refactorsuspected cause attached to the incident

  4. Investigating.

    Stack frames are mapped to files in your indexed codebase and the real source is pulled. The root cause analysis is grounded strictly in your code: no invented files, no invented symbols.

    frame cart/summary.ts:112 → mapped to the indexed reporeal source pulled from the branch you ship fromroot cause: discount path returns an undefined subtotal

  5. Fix ready.

    The same agentic runner that powers Autter's reviews writes the fix and opens a pull request on its own branch. The incident carries a problem, impact, and solution summary, and your reviewers get pinged.

    branch autter/fix-incident-482 · fix PR #489 openedsummary attached: problem · impact · solutionemail sent to on-call reviewers

  6. Deployed.

    You review, approve, and merge. Autter opens pull requests; humans keep the merge button.

    PR #489 approved and merged by your teamdeploy 4b19e77 · fix live in production

  7. Monitoring.

    After the fix ships, the incident stays open while occurrence counts are watched. Silence is measured, not assumed.

    occurrences since deploy 4b19e77: 0watching release health

  8. Resolved.

    The incident closes with the whole record attached: every occurrence, the correlation, the investigation, the fix, and who approved it.

    incident #482 closedfull record retained: trace → cause → fix → merge

A fix is only as good as its context.

Autter does not paste a stack trace into a model and hope. Four records converge on every case file before a fix is attempted, and each one is pulled from your stack, not inferred from the error text.

Frames become files
Each stack frame is matched against the indexed repository, exact path first, unique suffix next, and the real source is fetched from the branch you ship from.
Deploys become suspects
Deployment events in the window before the first occurrence are matched by commit to the merged pull request that shipped them.
Code stays the ground truth
The investigation is grounded strictly in fetched source. If your code cannot support a claim, the claim does not ship.
The same map your reviews use
Runtime shares the code intelligence index Autter already builds for review, so production context and review context are one map, not two.

Point your signals at it.

Runtime starts with an SDK you can read in an afternoon: open source, a few kilobytes in the browser, OpenTelemetry on the server. Connectors for the observability stack you already run are on the way.

@autter/runtime-browser

Errors and usage from the browser, a few kilobytes behind a publishable client key. Light enough that nobody argues about adding it.

@autter/runtime-node

Server-side errors and OpenTelemetry signals, plus a same-origin relay for the browser tracker.

@autter/runtime-next

Both halves wired into Next.js with one import.

Self-driving, with your hands near the wheel.

The loop runs unattended exactly as far as judgment allows, then it pings you. Four clauses hold on every incident.

PRs, never merges
Every fix arrives as an ordinary pull request from the Autter bot on its own branch. Your review process applies, and nothing lands without a human approval.
It asks before it guesses
When the fixer cannot confirm the fix from your code, it stops and asks your team two to five pointed questions, then resumes with the answers.
Pinged where you already read
The moment a fix PR opens, or questions are waiting, the reviewers who opted in get an email with the whole case attached.
Tuned to stay quiet
Only error-level issues can become incidents, and warnings never page. A fatal occurrence escalates an open incident instead of opening a second one.

The 3 a.m. page becomes a 9 a.m. pull request.

Autter runs the whole loop while you sleep: detects the error, folds the noise, finds the deploy that caused it, writes the fix, and opens the PR. It stops exactly where judgment starts, because self-driving still needs a driver's seat.

The production loop

Wake up to the fix, not the fire.

Install the Runtime SDK, connect your repo, and the next production error arrives as a triaged incident with the fix PR already open.

Start with RuntimeBook a demo