A spike of TypeError: undefined is not an object hits Sentry an hour after deploy. The stack is source-mapped, the breadcrumbs show what users did, and the release diff shows what changed — three evidence streams an AI can correlate into ranked hypotheses with user-impact estimates, before anyone touches code on a hunch.
Tier: Core · Workflow area: Performance & debugging
This playbook is the frontend on-call protocol: assemble the evidence bundle, get AI-ranked hypotheses with citations, verify the top one by reproduction, then fix — with impact quantified well enough to choose between hotfix, rollback, and Monday.
Skip it when the error's cause is obvious from the stack alone — read, fix, done. The correlation machinery earns its cost on the ambiguous ones.
release: web@1.42.0) so "first seen in" is trustworthy, plus breadcrumbs (navigation, clicks, fetches, console) enabled.git log between the previous release tag and the offending one.Assemble the evidence bundle — before any theorizing. For the error group, collect: the source-mapped stack (top frames with code context); occurrence stats (count, unique users, first-seen release, trend); the tag breakdown (browser, OS, URL/route, locale — skew here is itself a clue); three representative breadcrumb trails, not just one; and the release diff filtered to plausibly-related paths. Ten minutes of assembly makes the next step sharp instead of generic.
Ask for ranked hypotheses with citations against the bundle.
Production error triage. Evidence attached: source-mapped stack, stats
and tag breakdown, 3 breadcrumb trails, and the diff for release
web@1.42.0 (first-seen release).
Produce up to 4 hypotheses, ranked. For each:
1. The causal story: what user action + state reaches this line with
this value.
2. Evidence FOR, citing specifics (frame, breadcrumb entry, diff hunk).
3. Evidence AGAINST or missing.
4. A concrete check that would confirm or kill it (repro step, log
query, code inspection).
Then estimate user impact: who hits this, at what point in the funnel,
and whether the UI recovers or dead-ends. Do not propose fixes yet.
The "do not propose fixes yet" matters: models leap to plausible patches that anchor the investigation. Hypotheses first, each with a kill-check.
Run the kill-checks on the top hypotheses. Confirm by reproduction where possible: follow the breadcrumb trail in a local build against the release tag, with the tag-breakdown's conditions (that browser, that locale, that route). Where reproduction is hard, use the named log query or a targeted code inspection of the cited diff hunk. A hypothesis that survives its own kill-check and reproduces the exact stack is confirmed; anything less stays a hypothesis — and the fix waits.
Size the impact and choose the response lane. With the cause confirmed, firm up the numbers: percentage of sessions affected, position in the funnel (checkout error ≠ settings-page error), whether users recover (retry works?) or are blocked, and trend (accelerating with rollout percentage?). Map onto the rubric: rollback (broad, blocking, and the diff is cleanly revertable), hotfix (narrow cause, high impact), or scheduled fix (low impact, recoverable). Write the one-paragraph incident note — error, cause, impact, lane — where the team can see it; this is also what post-incident review will thank you for.
Fix with a regression test born from the repro, and watch the release. The reproduction from step 3 becomes the test — unit test if the cause was logic, RTL/Playwright if it was interaction-and-state. Ship via the chosen lane, then verify in the tracker: the error group's occurrence rate for the fixed release drops to zero (resolve-by-release, so a regression reopens it automatically). If the fix was a rollback, the forward-fix PR carries the test before the change ships again.
Triage is correlation, not inspiration: stack, breadcrumbs, tags, and the release diff, cross-examined into ranked hypotheses that each carry a kill-check. AI does the correlation in minutes; nothing gets fixed until one hypothesis has survived reproduction.
t.map is not a function in chunk-7f3a.js are astrology. If maps are missing for the release, fixing that pipeline outranks fixing the bug.Error events contain URLs, user context, and code — often the most sensitive bundle in this track.
Never paste raw production error events into public tools without scrubbing — breadcrumb trails routinely contain emails, tokens in URLs, and user content. Scrubbing is a tracker configuration, not a per-incident memory test.