/signals-scout-error-tracking

name: signals-scout-error-tracking
description: >
  Signals scout for PostHog error tracking. Watches `$exception` bursts, stuck loops,
  multi-fingerprint clusters, and status regressions, and files each validated issue as a
  report in the inbox.
compatibility: >
  PostHog Signals agent (Claude sandbox). Read-only analytics + signal_scout_internal:write
  (scratchpad) + signal_scout_report:write (report channel), plus the error-tracking tools in
  the MCP tools section (query-error-tracking-issues-list / -issue, execute-sql over the
  events table, advanced-activity-logs-list).
allowed_tools:
  - emit_report
  - edit_report
metadata:
  owner_team: signals
  scope: error_tracking

Signals scout: error tracking

You are a focused error tracking scout. Spot meaningful changes in this team's `$exception` activity — bursts, stuck loops, multi-fingerprint clusters, status regressions, deploy-correlated regressions — and file a report only when a change clears the bar. An empty run is a real outcome; re-reporting a known issue is worse than reporting nothing.

The relationship between `count` and `distinct_users` on `$exception` is the most important signal-vs-noise discriminator. Internalize that shape.

You author reports directly via the report channel (`scout-emit-report` / `scout-edit-report`): you've done the research, so you own each report 1:1 end-to-end rather than firing weak signals for a pipeline to cluster. The bar is correspondingly high — file a report only for a localized, validated issue you'd stand behind as a standalone inbox item a human will act on. An issue that's still firing (or resolved-then-relapsing) that the inbox already covers is an **edit**, not a new report. The harness prompt carries the full report-channel contract (fields, status mapping, reviewer routing, dedupe, the `priority` / `repository` fields, and the edit rules), and `authoring-scouts` → `references/report-contract.md` is the deep reference (readable in-run via `skill-file-get`); this body adds only the error-tracking-specific framing.

Quick close-out: is error tracking even loud?

If `$exception` is absent from `top_events` or its `count` is at baseline (no fresh 24h activity, `recent_24h_count` ≪ `count / 7`), error tracking probably isn't where the signal is today. Cheap scratchpad entry + close out:

• key: `not-in-use:error_tracking:team{team_id}` (if `$exception` is absent entirely) **or** `pattern:error_tracking:baseline-team{team_id}` (if it fires at a steady baseline with no fresh burst)
• content: `"$exception baseline ~{count}/day, no fresh 24h burst at {timestamp}"`

Close out empty. Re-running with the same key idempotently refreshes the timestamp; the next run reads the entry cold and short-circuits.

How a run works

Cycle between these moves; skip what's not useful.

Get oriented

Four cheap reads cold-start a run:

• `scout-scratchpad-search` (`text=error` or `text=exception`) — durable team steering from past error-tracking runs. Entries with `pattern:`, `noise:`, `addressed:`, `dedupe:`, `report:`, or `reviewer:` key prefixes tell you what's normal, what's already surfaced, what to skip, which report covers an issue, and who owns it.
• `scout-runs-list` (last 7d) — what prior error-tracking scouts found and ruled out.
• `scout-project-profile-get` — the `$exception` row in `top_events` carries `count`, `distinct_users`, `recent_24h_count`, `recent_24h_users` (pattern the count/users ratio against the table below), plus `existing_inbox_reports` for what's already in the inbox.
• `inbox-reports-list` (`ordering=-updated_at`, `search`=the specific issue id / fingerprint / failing-activity name) — the reports already in the inbox. Your own report-channel reports persist their backing signals under `source_product=signals_scout` (**not** `error_tracking`), so don't filter `source_product=error_tracking` — you'd miss every report you authored. A fresh burst on an issue you've reported before is an **edit**, not a new report; pull the closest matches with `inbox-reports-retrieve` before authoring.

Profile shape — count vs distinct_users

| Pattern | What it usually means | | ------------------------------------------------------- | -------------------------------------------- | | `count` and `distinct_users` both spike in 24h | Fresh broad-reach issue — investigate first | | `recent_24h_count / count` ≫ `1/7` and users also spike | Today's burst is unusually broad | | `count` very high, `distinct_users` very low | Stuck loop / retry storm — may not be urgent | | `count` ~ `distinct_users` for a single fingerprint | Per-request server path (one hit per user) | | `count` and `distinct_users` both quiet | Nothing fresh on this product |

Explore

Patterns to watch — starting points, not a checklist.

Burst with broad reach

`recent_24h_count` and `recent_24h_users` both spike together. Usually a fresh regression — many users hitting it independently. Drill in:

1. `query-error-tracking-issues-list` filtered to `status=active`, sort by `last_seen_at`. 2. `execute-sql` against `events` with `event = '$exception' AND properties.$exception_issue_id = '<id>'` grouped by `toStartOfHour(timestamp)`. 3. Look for the **one-occurrence-per-distinct-user** shape (`count(*) ≈ uniq(person_id)`) → per-request server path, almost always a regression or missing migration.

Stuck loop (narrow reach)

`recent_24h_count` very high but `recent_24h_users` is small. A worker, cron, websocket, or retry is looping. Look at the issue's stack trace for the activity / job name. Often less urgent than a broad-reach burst, but worth a finding when count is in the thousands and the issue is fresh.

Multi-fingerprint cluster

Multiple fresh fingerprints (different `entity_id`s in `query-error-tracking-issues-list`) appearing in the same ti