---
title: Autter Runtime - Observability Agents That Fix Production Errors
description: Autter Runtime watches production through a lightweight open source SDK, folds raw errors into incidents, traces each one to the deploy and pull request that caused it, investigates against your indexed codebase, and opens the fix as a PR for a human to review.
url: https://autter.dev/features/runtime
site: Autter - Autter is your AI teammate for code review and testing: it reviews code, tests product impact, checks security, governs releases, and closes the loop from production failure to verified fix.
---

## Runtime Observability at a glance

| Fact | Value |
| --- | --- |
| Role | The production loop: errors detected, grouped, correlated, investigated, and returned as fix PRs |
| Signal source | The open source Autter Runtime SDK (browser, Node, Next.js). Sentry, PostHog, and Grafana connectors are on the roadmap, not live yet |
| Promotion rules | Only error-level issues can become incidents: a spike past the threshold or one fatal occurrence. Warnings never page |
| Fix delivery | A GitHub pull request from the Autter bot on its own branch; humans review and merge |
| When uncertain | Asks the team two to five clarifying questions by email instead of guessing, then resumes with the answers |
| Notifications | Email to opted-in reviewers the moment a fix PR opens or questions are waiting |

## How it works, step by step

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.
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.
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.
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.
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.
6. **Deployed.** You review, approve, and merge. Autter opens pull requests; humans keep the merge button.
7. **Monitoring.** After the fix ships, the incident stays open while occurrence counts are watched. Silence is measured, not assumed.
8. **Resolved.** The incident closes with the whole record attached: every occurrence, the correlation, the investigation, the fix, and who approved it.

## What the loop runs on.

Every stage is mechanical and inspectable, from the fingerprint that folds the noise to the questions it asks when it is not sure.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | Fingerprint grouping | Raw occurrences fold into issues by error type, normalized message, and top stack frames, so a thousand pages become one line with a count. |
| 2 | Incident promotion | Only error-level groups can become incidents: a spike past the threshold or a single fatal occurrence opens one. Warnings never page anyone. |
| 3 | Deploy correlation | New incidents are checked against recent deployments and matched to the merged pull request that shipped the change. |
| 4 | Grounded investigation | Stack frames map to your indexed codebase and the real source is fetched, so the root cause cites code that actually exists. |
| 5 | Fix pull requests | Fixes arrive as ordinary GitHub pull requests on their own branch, opened by the Autter bot for a human to review and merge. |
| 6 | Clarifying questions | When the fixer is not sure, it does not guess. It asks your team two to five pointed questions and resumes with the answers. |

## In one line

> 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 incident lifecycle

Every incident moves through the same eight stages, rendered as a stepper in the Autter dashboard. Generated from the same data the page renders.

| # | Stage | What happens |
| --- | --- | --- |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 6 | Deployed | You review, approve, and merge. Autter opens pull requests; humans keep the merge button. |
| 7 | Monitoring | After the fix ships, the incident stays open while occurrence counts are watched. Silence is measured, not assumed. |
| 8 | Resolved | The incident closes with the whole record attached: every occurrence, the correlation, the investigation, the fix, and who approved it. |

## The Runtime SDK

Open source at https://github.com/Autter-dev/autter-runtime. Install with `npm install @autter/runtime-browser` (or the Node/Next.js package). Ingest keys are scoped: server keys stay on the server, publishable client keys are safe to ship in the browser.

| Package | What it does |
| --- | --- |
| `@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. |

Connectors for Sentry, PostHog, Grafana are on the roadmap (not live yet); they will feed the same loop from grouping onward.

## How context is assembled before a fix

- **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.

## Human-in-the-loop guarantees

- **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.

## Related

- [Code Review](https://autter.dev/features/code-review.md)
- [Analytics](https://autter.dev/features/analytics.md)
- [Integrations](https://autter.dev/features/integrations.md)
- [Full product overview](https://autter.dev/index.md)