diff --git a/AGENTS.md b/AGENTS.md index 6d6f0b3..5e07e28 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -26,6 +26,9 @@ - Use “AI authorship” and “line-level attribution,” not “AI detection.” - Use “coding agent” for tools such as Codex, Claude Code, Cursor, and GitHub Copilot. - Use “organization,” “repository,” “pull request,” and “merge request” where appropriate. +- Use “Autter Runtime” only for the production telemetry product (the open source SDKs and ingester). +- Use “review sandbox” for the isolated environment where the platform checks out, builds, or tests a pull request. Never call it a runtime. +- Avoid generic “runtime” phrasing elsewhere; prefer “performance,” “execution,” or “while running” so “Runtime” stays unambiguous. ## Style preferences diff --git a/cli/install.mdx b/cli/install.mdx index 3a1c322..7409cbd 100644 --- a/cli/install.mdx +++ b/cli/install.mdx @@ -56,38 +56,43 @@ For fish, use `source "$HOME/.autter/env.fish"`. New terminals pick up the `PATH Interactive macOS, Linux, and WSL installs start onboarding automatically. If the installer runs without an interactive terminal, complete onboarding later with `autter onboard`. -## Complete onboarding +## What the installer changes -The installer asks whether you want local-only or connected mode. +Every install method makes the same changes, all scoped to your user account: - - Placeholder for the Autter CLI onboarding choices - +| Change | Detail | +| --- | --- | +| Binary | `~/.autter/bin/autter` (Windows: `%USERPROFILE%\.autter\bin\autter.exe`). On macOS and Linux, a convenience symlink at `~/.local/bin/autter` when that directory exists. | +| `PATH` | Writes `~/.autter/env` (and `~/.autter/env.fish`), then appends one line that sources it — marked `# Added by autter installer` — to the shell files that exist on your machine: `~/.bashrc`, `~/.bash_profile`, `~/.zshrc`, or `~/.config/fish/config.fish`. On Windows, adds `%USERPROFILE%\.autter\bin` to your user `PATH` (never the system `PATH`) and, when Git Bash is detected, a `PATH` export in `~/.bashrc`. | +| Settings and state | Settings in `~/.autter/config.json`. Credentials in your operating system keyring when available, otherwise in `~/.autter/internal/credentials` with owner-only permissions. The telemetry audit log at `~/.autter/internal/telemetry.log`. | +| Coding-agent integrations | Adds checkpoint hooks to each detected agent's own configuration (for example, Claude Code's `~/.claude/settings.json`) so edits are attributed as they happen. Refresh anytime with `autter install-hooks`. | +| Git observation | Sets the global `trace2.eventTarget` and `trace2.eventNesting` Git configuration keys so the background service can observe when commits complete. Trace2 is Git's built-in event stream; it does not change how Git behaves. | +| Background service | Starts the Autter background service, which turns recorded checkpoints into Git notes under `refs/notes/ai` after each commit. | - - - Choose local-only mode to keep prompts on the machine and use Git notes for attribution. +Autter does not install Git hooks, does not wrap the `git` command, and does not edit any per-repository configuration. - You can select it again later: - - ```bash - autter onboard --local --force - ``` - - - Choose connected mode to sign in and sync attribution to the Autter platform. +## Complete onboarding - You can start the flow later: +Interactive installs start `autter onboard` automatically; run it yourself anytime. The guided flow takes about a minute and asks two questions. - ```bash - autter onboard - ``` + + Placeholder for the Autter CLI onboarding choices + - To select connected mode directly, run `autter onboard --connect`. - - If onboarding cannot complete, use the [PAT fallback](/cli/connect-platform#pat-fallback). - - + + + - **Connected** links the machine to your Autter organization. Sign-in opens in your browser; the CLI never sees your password. Attribution is still written to local Git notes, and prompt and usage data also syncs to your organization's dashboards. If browser sign-in cannot complete, use the [PAT fallback](/cli/connect-platform#pat-fallback). + - **Local-only** keeps everything on the machine. No account is needed and nothing uploads. Switch anytime with `autter onboard --connect`. + + + Autter asks before sending anonymous usage analytics: a random install ID, coarse device info, and the Autter version — never code, prompts, or personal data. Every event sent is mirrored to `~/.autter/internal/telemetry.log` so you can audit it, and `autter telemetry off` disables it at any time. + + + The background service restarts with your choices, and authorship is recorded on every commit from here on. After your next AI-assisted commit, try `autter stats`, `autter blame `, or `autter log`. + + + +To redo onboarding, run `autter onboard --force`. For unattended setups, script the same choices with flags: `autter onboard --local --no-telemetry` or `autter onboard --connect`. ## Verify the installation @@ -130,6 +135,44 @@ Use `autter upgrade --force` to reinstall the latest release. This works for every install method, including npm: the npm package is only a bootstrapper, and `autter upgrade` (or the background service's automatic update) replaces the binary in `~/.autter/bin` directly. Running `npm update -g @autter/cli` is not required. +## Uninstall + +Removal is the install in reverse. Autter keeps its state under `~/.autter`, so there is nothing scattered to hunt down. + + + + ```bash + autter bg shutdown + autter uninstall-hooks + ``` + + `autter uninstall-hooks` removes the checkpoint entries Autter added to your coding agents' configuration files. If the machine was connected, run `autter logout` first to clear credentials. + + + ```bash + git config --global --unset trace2.eventTarget + git config --global --unset trace2.eventNesting + ``` + + + ```bash + rm -rf ~/.autter + rm -f ~/.local/bin/autter + ``` + + On Windows, run `Remove-Item -Recurse -Force "$HOME\.autter"`, then remove `%USERPROFILE%\.autter\bin` from your user `PATH` under **Settings → Environment variables**. + + + Delete the block marked `# Added by autter installer` from `~/.bashrc`, `~/.bash_profile`, `~/.zshrc`, or `~/.config/fish/config.fish` — whichever exist. For Git Bash on Windows, remove the same block from `~/.bashrc`. + + + +Attribution already recorded in your repositories is not touched: it lives in each repository's Git notes under `refs/notes/ai`. To remove it from one repository, run `git update-ref -d refs/notes/ai` there. Uninstalling also does not delete data previously uploaded in connected mode — see [Opt out of cloud storage](/cli/data-and-privacy#opt-out-of-cloud-storage). + + + To stop syncing without uninstalling, switch the machine to local-only mode with `autter logout` followed by `autter onboard --local --force`. To turn Autter off for a single repository, see [Disable Autter for a repository](/cli/data-and-privacy#disable-autter-for-a-repository). + + ## Next step diff --git a/cli/overview.mdx b/cli/overview.mdx index 7195350..1bbc4f5 100644 --- a/cli/overview.mdx +++ b/cli/overview.mdx @@ -81,7 +81,7 @@ Autter does not guess whether code came from AI. Supported coding agents create Jump into the main reference hub for the CLI. - Learn what affects CLI runtime on large repos. + Learn what affects CLI performance on large repos. Follow the integration path for a new coding agent. diff --git a/cli/reference.mdx b/cli/reference.mdx index c5f6112..ac640ee 100644 --- a/cli/reference.mdx +++ b/cli/reference.mdx @@ -19,7 +19,7 @@ If you need the full command list, open the [command reference](/cli/command-ref Review local-only, connected, and team storage behavior. - Understand the CLI's runtime impact and scaling behavior. + Understand the CLI's performance impact and scaling behavior. Fix missing attribution, connection problems, and service issues. diff --git a/cli/windsurf.mdx b/cli/windsurf.mdx index e8c46b7..74510df 100644 --- a/cli/windsurf.mdx +++ b/cli/windsurf.mdx @@ -43,5 +43,5 @@ autter blame src/service.ts ``` - Check the CLI's runtime impact before rolling it out broadly. + Check the CLI's performance impact before rolling it out broadly. diff --git a/configuration/overview.mdx b/configuration/overview.mdx index 9ae2758..4a13e98 100644 --- a/configuration/overview.mdx +++ b/configuration/overview.mdx @@ -42,7 +42,7 @@ Use Autter platform settings to control what Autter reviews and how your team re Enable focused checks for the repository's languages, frameworks, and risk profile. - Roll the same configuration to more repositories after the team agrees on the signal quality. + Roll the same configuration to more repositories after the team agrees on the signal quality. Use the acted-on rate on each repository's Health tab to judge it — see [Calibration](/features/calibration). diff --git a/docs.json b/docs.json index 3276ead..72e41f3 100644 --- a/docs.json +++ b/docs.json @@ -117,6 +117,7 @@ "pages": [ "features/platform-overview", "features/code-review", + "features/calibration", "features/codebase-scans", "features/wiki", "features/pipeline", @@ -175,6 +176,7 @@ { "group": "Reference", "pages": [ + "runtime/error-lifecycle", "runtime/environment-variables", "runtime/architecture" ] diff --git a/features/ai-chat.mdx b/features/ai-chat.mdx index f803a74..3565d26 100644 --- a/features/ai-chat.mdx +++ b/features/ai-chat.mdx @@ -30,6 +30,10 @@ Use AI chat to ask about complex logic, architecture, repository patterns, or a Ask focused questions and name the relevant module or behavior. Specific questions make it easier to verify the answer against code. +### What chat can read + +Chat is grounded in the same context as [review](/features/code-review#what-autter-reads-during-a-review): the repository index, the generated repository docs, and — on a pull request — the diff, the comment thread, and existing findings. When you mention `@autter` on a pull request, the agent additionally works from a checkout of the pull request head in an isolated review sandbox, so it can open any file in the repository to answer. Questions run read-only; asking for a fix uses the same sandbox and pushes a branch for your review. + ## Suggested fixes Autter can propose concrete fixes for review findings. Before applying one: @@ -48,7 +52,7 @@ Autter can propose concrete fixes for review findings. Before applying one: - write narrow, testable [review rules](/configuration/rules) - connect relevant issues and documentation - keep pull requests focused -- use thumbs feedback where available to help calibrate results +- give thumbs and reaction feedback on findings — it feeds [calibration](/features/calibration) directly - revise rules that repeatedly flag valid code {/* TODO: Add the exact chat entry points and feedback controls after the production UI is approved. */} diff --git a/features/calibration.mdx b/features/calibration.mdx new file mode 100644 index 0000000..0b52911 --- /dev/null +++ b/features/calibration.mdx @@ -0,0 +1,73 @@ +--- +title: "Calibration" +description: "How Autter measures whether findings earn attention and tunes every repository's review from your team's feedback." +--- + +An AI review is only useful if its findings get acted on. Autter treats that as a measurable number per repository, feeds reviewer feedback back into the next review, and demotes checks that cost attention without earning it. This page collects the whole loop in one place. + +## The signals Autter learns from + +Autter reads feedback the way your team already gives it — no extra process required: + +| Signal | What it tells Autter | +| --- | --- | +| Fixed before merge | The flagged lines changed between the review and the merged code | +| Thumbs feedback | A direct rating on a finding, where available | +| Replies | Pushback or agreement on a finding's thread | +| 👎 reactions | A negative reaction on a finding comment | +| Deleted comments | A maintainer removed an Autter comment | +| Resolved without change | The thread was resolved while the flagged code stayed as it was | +| Ignored | The pull request merged with the flagged lines untouched and no other signal | + +When a pull request closes, Autter records an outcome — **fixed**, **dismissed**, or **ignored** — for every finding that was actually shown to a reader. Findings on pull requests that close without merging are excluded, so abandoned work never skews the numbers. + +## The acted-on rate + +The **Review signal** section on a repository's **Health** tab shows the acted-on rate: of the findings Autter surfaced, how many were fixed before merge versus dismissed or ignored. + +- **Overall acted-on rate** — one headline number for the repository. +- **Week-by-week trend** — whether the review is getting more or less useful over time. +- **Worst-first breakdown by check** — the checks costing attention without earning it sit at the top. +- **In your digest** — the headline number and the worst-performing check are included in the weekly digest email and Slack message. + +## What the feedback changes + +Four mechanisms turn those signals into different future reviews. + +### Learnings + +Feedback becomes repository-scoped learnings: durable conventions Autter applies to every later review of the same repository. Learnings never leak across repositories. View, accept, or reject them on the repository's **Learnings** tab, and let coding agents read or add them over [MCP](/features/mcp) with `get_learnings` and `add_learning`. + +### Muting + +Dismissing a finding — deleting the comment, a 👎 reaction, a pushback reply, or resolving the thread without changing the code — mutes that check on that file path in future reviews. The mute is stored as a learning, so it is visible and reversible on the **Learnings** tab. + +### Auto-demotion + +A check with a persistently low acted-on rate in your repository is automatically moved out of the way, in stages: first out of inline comments and into the review summary, then out of the pull request entirely. Demotion looks at the trailing 90 days of merged pull requests, so checks recover on their own when they start being useful again — and a full demotion appears on the **Learnings** tab, where rejecting it reverses the demotion. + +### Verification skepticism + +Precision history feeds the verification pass that runs before findings post. A check your team chronically dismisses needs stronger evidence to publish a finding; a check you consistently act on gets the benefit of the doubt. + +## Reviewer training + +Autter can also learn from reviews your team wrote before Autter existed. Name trusted reviewers for a repository, and Autter mines their past pull request comments, keeps the substantive ones, and distills up to twenty repository guidelines that are applied like accepted learnings. Re-running training replaces the previously trained guidelines, so the output always reflects the current trainer list. Training is opt-in per repository. + +## Controls + +- Learnings can be turned on or off for the organization and per repository. +- Per repository, choose which signals create learnings: thumbs feedback, dismissed findings, and applied auto-fixes. +- The trainer list for reviewer training is set per repository. +- Every mute and demotion is a visible entry on the **Learnings** tab and can be rejected to reverse it. + +{/* TODO: Add exact navigation labels for the Health and Learnings tabs once the production UI is approved for documentation. */} + + + + See what context a review reads and how findings are produced. + + + Write the explicit standards that calibration then keeps honest. + + diff --git a/features/code-review.mdx b/features/code-review.mdx index 75987fd..94d1cac 100644 --- a/features/code-review.mdx +++ b/features/code-review.mdx @@ -30,18 +30,19 @@ Autter is designed to find issues that can survive a surface-level review: - dependency and scanner findings relevant to the diff - behavior that appears correct in isolation but fails in the wider codebase -## How context changes the review +## What Autter reads during a review -A generic rule might flag every direct database call. A codebase-aware review can distinguish between an approved repository layer and a controller that bypasses it. +"Codebase-aware" has a specific meaning. A review reasons over three layers of context: -Autter can ground feedback in: +1. **The diff.** Autter fetches the pull request's compare diff from your source control provider. Every review starts from the changed lines. +2. **The repository index.** When you connect a repository, Autter indexes it: dependency and call graphs, per-file and per-symbol summaries, hotspots, and architecture and convention notes. During a review, Autter walks the index outward from the changed files — direct callers and callees, same-module neighbors, and heavily depended-on paths the change can affect — and fetches those specific files on demand through the provider API. The standard review does not clone your repository. +3. **Connected knowledge.** Natural-language team rules, accepted [learnings](/features/calibration), linked issues, and reference documents attached to the repository, such as product or design docs and URLs. Attached documents contribute bounded summaries that are fenced off from code and findings: they inform the review, they cannot instruct it. -- related files and dependencies -- established repository patterns -- natural-language team rules -- prior review comments and team knowledge -- linked issues and documentation -- current linter and scanner results +Deeper stages get more access. When findings need verification, a fix is generated, or build and test checks run, Autter checks out the pull request head at its exact commit into an isolated, single-use **review sandbox**. There it can search the full tree and run your build and tests. The sandbox is destroyed when the job ends. + +A review never reads other repositories in your organization — context is scoped to the repository under review — and never reads documents you have not connected. + +This context is what separates codebase-aware review from generic rules. A generic rule might flag every direct database call; because Autter sees the repository index, it can distinguish an approved repository layer from a controller that bypasses it. ## Use team rules @@ -67,7 +68,7 @@ Keep rules specific and testable. See [Review rules](/configuration/rules) and [ Push changes and review the latest Autter result alongside human feedback. - Refine a rule or pipeline check when it repeatedly flags valid code. + Refine a rule or pipeline check when it repeatedly flags valid code. Autter also [demotes low-precision checks automatically](/features/calibration). diff --git a/features/codebase-scans.mdx b/features/codebase-scans.mdx index 2e14053..89fce04 100644 --- a/features/codebase-scans.mdx +++ b/features/codebase-scans.mdx @@ -27,7 +27,7 @@ The hosted product may expose focused scan categories for areas such as: - secrets and sensitive configuration - license compliance - static security analysis -- API surface and runtime compatibility +- API surface and version compatibility - code quality and architecture - business logic and payment flows - frontend health and accessibility @@ -41,7 +41,7 @@ The hosted product may expose focused scan categories for areas such as: Prioritize exploitable security issues, exposed credentials, authorization failures, and data integrity risks. - Open the affected code and confirm that the finding reflects runtime behavior and repository context. + Open the affected code and confirm that the finding reflects the code's real behavior and repository context. Fix shared causes such as an outdated dependency, missing authorization layer, or repeated unsafe pattern. diff --git a/features/platform-overview.mdx b/features/platform-overview.mdx index 3efddf9..4b2e381 100644 --- a/features/platform-overview.mdx +++ b/features/platform-overview.mdx @@ -66,6 +66,8 @@ The Autter platform reviews proposed code changes before merge. It combines code | Documentation | README files, architecture records, and other connected docs | | Linters and scanners | Deterministic findings that Autter can filter and explain | +For precisely what a review reads — the diff, the repository index, connected knowledge, and when the isolated review sandbox is used — see [What Autter reads during a review](/features/code-review#what-autter-reads-during-a-review). For how review history tunes future reviews, see [Calibration](/features/calibration). + ## Platform and CLI The Autter platform and Autter CLI solve different parts of the workflow. The platform reviews a proposed change. The CLI records who or what authored each line. diff --git a/runtime/error-lifecycle.mdx b/runtime/error-lifecycle.mdx new file mode 100644 index 0000000..3b8ffcf --- /dev/null +++ b/runtime/error-lifecycle.mdx @@ -0,0 +1,98 @@ +--- +title: "Anatomy of an exception" +description: "Follow one Node.js exception end to end — capture in your process, transport, ingest and normalization, fingerprinting, storage, and the issue and incident you see in Autter." +--- + +This page traces a single Node.js exception through the whole pipeline, so you know exactly what each stage does and where to look when something surprises you. + +```mermaid +flowchart LR + A["throw in your app"] --> B["SDK capture"] + B --> C["POST /v1/traces"] + C --> D["normalize + fingerprint"] + D --> E["ClickHouse (raw)"] + D --> F["sink → issue + incident"] +``` + +## The example + +A payments service is instrumented with the preloaded `instrument.cjs` from the [quickstart](/runtime/quickstart): + +```js +// instrument.cjs — preloaded via: node --require ./instrument.cjs server.js +const { initAutterServer } = require("@autter/runtime-node"); + +initAutterServer({ + apiKey: process.env.AUTTER_RUNTIME_KEY, + service: "payments-api", + environment: "production", + release: process.env.GIT_SHA, +}); +``` + +One route has a bug — a lookup can return `undefined`: + +```js +app.post("/orders/:id/charge", async (req, res) => { + const order = await orders.find(req.params.id); + await chargeCard(order.card); // order is undefined → TypeError + res.json({ ok: true }); +}); +``` + +A request for a deleted order throws `TypeError: Cannot read properties of undefined (reading 'card')`. + +## 1. Capture, in your process + +Two paths lead into the same pipeline: + +- **Handled errors** — you call `captureException(err, attributes)`. The SDK records the error as a span named after the error type, with the stack trace, `autter.severity: "error"`, and any attributes you pass (`{ "order.id": order.id }` becomes queryable metadata). +- **Crashes** — the SDK observes unhandled exceptions with a monitor that does not change how your process exits. The error is reported with `autter.unhandled: true`, which the pipeline treats as `fatal` severity, and the SDK makes a best-effort flush before the process dies. + +Your `service`, `environment`, and `release` are stamped once at init time and ride along on every event — you never repeat them per capture. + +Errors do not compete with trace sampling. Regular request traces are sampled (about 1% by default); errors travel a dedicated always-on pipeline that batches for about two seconds and can never be sampled away. + +## 2. Transport + +The SDK sends OTLP/HTTP JSON to your ingester's `/v1/traces` endpoint, authenticated with the server key as a bearer header. If the ingester cannot write storage, it answers `503` instead of accepting and dropping — the exporter retries, so a storage hiccup delays data rather than losing it. + +## 3. Ingest and normalize + +The ingester resolves the key to one organization and repository, decodes the payload (JSON or protobuf), and walks the spans. Every exception event becomes one **occurrence**: source, severity, service, environment, release, error type, message, stack, and route. An errored span with no exception event still produces an occurrence, so failures never vanish just because nothing threw. + +Normalization then strips the volatile parts and stores derived columns alongside the raw ones: + +- the message is templated — ids, UUIDs, numbers, and quoted strings become placeholders +- the route collapses — `/orders/812/charge` becomes `/orders/:id/charge` +- the top stack frames keep file and function but drop line and column offsets, which shift on every minified deploy + +## 4. Fingerprint — the grouping key + +The ingester hashes source, service, error type, the normalized message, the top five normalized frames, and the normalized route into a 32-character fingerprint. The same `TypeError` from ten users, three releases, and two orders is one fingerprint; a different error type in the same route is a different one. + +Severity is deliberately excluded: the same defect reported as a warning in one code path and an error in another stays one group. The full algorithm is in [Architecture & data model](/runtime/architecture#fingerprinting). + +## 5. Storage + +The occurrence lands as one row in `runtime_error_occurrences` in ClickHouse (raw errors, 14-day TTL). If the request's trace was sampled, its spans land in `runtime_spans`; per-minute usage rollups accumulate in `runtime_metrics_1m` regardless. This raw layer is what the quickstart's verification queries and the SQL explorer read. Raw signal is short-lived by design — everything worth keeping longer is derived downstream. + +## 6. Issue and incident + +The ingester forwards accepted batches to its sink — Autter's platform, or your own consumer if you self-host. Autter folds occurrences into an **issue** keyed by fingerprint plus service plus environment: total events, affected sessions, first and last seen, worst severity, and a sample stack. A resolved issue that recurs reopens automatically. + +An issue escalates to an **incident** when it records a fatal crash or keeps recurring (ten or more occurrences). Autter then looks at successful deployments from the previous 48 hours, links the suspect pull request when the deployed commit matches one, writes a summary of the likely cause, and can open a fix pull request. The incident timeline records each step: detected, grouped, correlated, resolved. + +## Where you see it + +- **Runtime tab** in the Autter dashboard — issues list, incident detail with the timeline and any linked fix pull request, and the SQL explorer over the raw tables. +- **Locally** — the ClickHouse queries in the [quickstart](/runtime/quickstart) show occurrences seconds after a test error. + + + + The schema, TTLs, and normalization rules behind each stage. + + + Instrument an app and trigger your first tracked exception. + + diff --git a/runtime/installation.mdx b/runtime/installation.mdx index 832a477..01e7e99 100644 --- a/runtime/installation.mdx +++ b/runtime/installation.mdx @@ -38,7 +38,7 @@ npm install @autter/runtime-next # Next.js (both halves in one package) ``` - One preloaded file, requests traced automatically: + One preloaded file, created in your own app next to its entry point — requests traced automatically: ```js // instrument.cjs — run with: node --require ./instrument.cjs server.js diff --git a/runtime/integrations.mdx b/runtime/integrations.mdx index 7b415a7..f18c1f8 100644 --- a/runtime/integrations.mdx +++ b/runtime/integrations.mdx @@ -47,6 +47,8 @@ React render errors: wrap with `` (from `@autter/runtime-ne npm install @autter/runtime-node ``` +Create `instrument.cjs` in your service's directory, next to its entry point: + ```ts // instrument.cjs — load first: node --require ./instrument.cjs server.js const { initAutterServer } = require("@autter/runtime-node"); diff --git a/runtime/introduction.mdx b/runtime/introduction.mdx index 6d497ae..c4a03d5 100644 --- a/runtime/introduction.mdx +++ b/runtime/introduction.mdx @@ -10,6 +10,10 @@ Autter Runtime tracks **runtime errors and usage** from your frontend and backen - your server keeps real OpenTelemetry - Autter Runtime's **OTLP ingester** receives both and writes them to ClickHouse in a compact, per-repository data model + + In these docs, **Autter Runtime** always means this product: the open source telemetry SDKs and ingest pipeline that watch your app in production. The isolated environment where the Autter platform builds and tests your pull requests is a different thing — the docs call it the **review sandbox**, described in [code review](/features/code-review#what-autter-reads-during-a-review). + + ```mermaid flowchart TD A["@autter/runtime-browser (tiny tracker)"] --> B["Same-origin relay (@autter/runtime-node)"] diff --git a/runtime/quickstart.mdx b/runtime/quickstart.mdx index 1208d81..f5fa077 100644 --- a/runtime/quickstart.mdx +++ b/runtime/quickstart.mdx @@ -44,7 +44,7 @@ Autter Runtime tracks runtime errors and usage from your frontend and backend wi npm install @autter/runtime-node ``` - Create `instrument.cjs` — it must load **before** your app: + In **your application's repository** — not the `autter-runtime` repository you may have cloned in step 1 — create `instrument.cjs` next to the entry point of the service you are instrumenting (one file per service in a monorepo). It must load **before** your app: ```js const { initAutterServer } = require("@autter/runtime-node");