Error triage & investigation

Two loops debug your product. Error triage starts from a crash the 1mn SDK captured and fixes the highest-impact one. Investigate starts from a symptom you describe, traces it to root cause, and always posts what it found — fixing it too when the fix is small and safe. Both work inside a sandbox with your connected GitHub repo.

Error triage — fix the crash users are hitting

When your app reports errors through the 1mn SDK, the triage loop reads the grouped, symbolicated exceptions and turns the single highest-impact one into a pull request.

Prerequisites

• The 1mn SDK installed and reporting. Without it there are no captured errors to triage, and the loop says so and stops.
• A connected GitHub repo to open the fix against.

How it works

1. Loads the assigned error. Auto-filed error tickets carry a Fingerprint: in the brief — that exact error is the target. The loop pulls its full symbolicated stack (frames resolved to original source like app/routes/x.tsx:42 when sourcemaps exist) plus recent occurrences (page URL, time, visitor) so it can see where and when it fires.
2. Finds the root cause. The symbolicated line is where it threw, not always where the bug is — so it reads the surrounding code, the caller, and the assumption that was violated (a missing null check, an unhandled rejection, a changed response shape).
3. Makes the smallest correct fix, matching your conventions, and opens a PR. If, after reading the code, the error isn't reproducible or fixable from the repo — third-party script noise, a browser-extension error, or something already fixed on main — it doesn't invent a change.

When the brief has no fingerprint (a manual run), it lists the open error groups and picks the highest-impact one — preferring high affected-user count, then occurrence count, then a rising trend. One error per run.

Investigate — find the root cause of a symptom

Investigate is for "why is X broken?" Its discipline is the order: understand → gather signals → reproduce/trace → find root cause → report → decide whether to fix. Proving what's actually wrong is the job; acting is the easy part.

How it works

1. Gathers only the relevant signals — the SDK error detail when the brief carries a Fingerprint:; your saved records and files when it's a data bug ("the report shows wrong numbers"); recent commits to bracket when a regression began; web search for an unfamiliar error string.
2. Clones the repo and traces the failure backward from the symptom to the line that causes it, reproducing where it helps — running your tests, the failing function, or loading a live URL from a real occurrence.
3. Always posts a findings comment — a brief, evidence-backed root cause on the ticket. This happens every run, even when it doesn't ship a fix.
4. Fixes it only when the cause is clear and the change is small and low-risk — then opens a PR alongside the findings. Otherwise it stops at the findings and recommends the next step.

What you get

• Error triage: a pull request fixing the single highest-impact captured error, or a short report when there's nothing actionable.
• Investigate: a root-cause findings comment on the ticket every time, plus a fix PR when the cause is clear and the fix is low-risk.

In both, the loop opens the PR — you review the diff and merge.

Notes & limits

• One problem per run. Triage fixes one error; Investigate traces one symptom.
• No fabricated signals. If a log or error trail isn't reachable, the findings say so rather than inventing log lines.
• Errors flow from the SDK. See the SDK page for installing it and how captured exceptions are grouped and symbolicated.