Help us improve
Share bugs, ideas, or general feedback.
From posthog
Prioritizes and triages PostHog error tracking issues by recency, users affected, and trend spikes. Points to linked replays and suggests next actions.
npx claudepluginhub anthropics/claude-plugins-official --plugin posthogHow this skill is triggered — by the user, by Claude, or both
Slash command
/posthog:triaging-error-issuesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
When a user asks "what's broken?" or wants a daily error review, the goal is a short
Investigates a PostHog error tracking issue end-to-end: aggregates, segments, replays, and synthesizes a hypothesis summary from an issue ID or URL.
Triage product errors by cross-referencing network failures, JavaScript errors, and error clicks via Amplitude to identify root causes and affected users.
Investigates recent errors and exceptions in Sentry projects: fetches issues via MCP, analyzes frequency, trends, stack traces, user impact, and suggests fixes for quick triage.
Share bugs, ideas, or general feedback.
When a user asks "what's broken?" or wants a daily error review, the goal is a short prioritized list of issues worth a human's attention — not a dump of every active issue. Most projects have hundreds of active issues; the few that matter are usually new (first seen in the last 24-48h), spiking, or affecting many distinct users.
| Tool | Purpose |
|---|---|
posthog:query-error-tracking-issues-list | List + rank issues with aggregate metrics (occurrences, users, sessions) |
posthog:query-error-tracking-issue | Compact details for a single issue (status, assignee, top frame, release) |
posthog:query-error-tracking-issue-events | Sampled $exception events with stack, URL, browser, and $session_id |
posthog:query-session-recordings-list | Find replays of users hitting an issue |
posthog:inbox-reports-list | Pre-curated actionable signals if the project uses Inbox |
Read the time window from the user's wording. Defaults if unspecified:
dateRange: { date_from: "-24h" }-7d-24hPick what "matters" means:
orderBy: "first_seen", orderDirection: "DESC", tight window.
Catches regressions introduced by recent deploys.orderBy: "users" ranks by distinct users affected. Better than
raw occurrences for severity (one bot loop produces many occurrences but one user).orderBy: "occurrences" over a short window vs a longer baseline
to spot spikes.Start narrow and widen if too few issues come back:
posthog:query-error-tracking-issues-list
{
"status": "active",
"orderBy": "users",
"orderDirection": "DESC",
"dateRange": { "date_from": "-24h" },
"limit": 20,
"volumeResolution": 24
}
Match volumeResolution to the window (24 buckets for -24h, 14 for -14d, etc.)
so each row's sparkline has enough resolution to show a spike vs flat steady state.
A single bucket only gives a total, not a shape.
For new-issues-only, run a parallel query with orderBy: "first_seen":
{
"status": "active",
"orderBy": "first_seen",
"orderDirection": "DESC",
"dateRange": { "date_from": "-24h" },
"limit": 10
}
If a project mixes browser and server SDKs, the top-by-users list is usually drowned
by server-side errors (each invocation often gets a fresh distinct_id). Narrow with
the library filter — values match the SDK's $lib, not the npm package name, examples:
web — posthog-js (browser)posthog-node, posthog-python, posthog-ruby, posthog-go, posthog-php, posthog-java, posthog-elixir — server SDKsposthog-edge — Cloudflare Workers / edge runtimeposthog-ios, posthog-android, posthog-react-native, posthog-flutter — mobileThe list will include known noise. Before presenting, drop or call out:
suppressing-noisy-errors) instead of triage.If unsure whether an issue is new vs. recurring, compare first_seen to the start
of the window:
first_seen inside the window → new, worth attentionfirst_seen weeks ago but spiking now → regression worth attentionfirst_seen weeks ago, flat volume → background noiseFor the top 3-5 candidates, pull a sample exception so the summary includes a stack
frame and URL, not just a title. Use posthog:query-error-tracking-issue-events rather than
raw SQL — it returns normalized fields ($exception_types, $exception_values,
$current_url, browser/OS, $session_id) and defaults to onlyAppFrames: true to
strip vendor noise from the stack:
posthog:query-error-tracking-issue-events
{
"issueId": "<issue_id>",
"limit": 1,
"verbosity": "stack"
}
If the user wants to see what users were doing, hand off to finding-replay-for-issue
to pick the best linked recording. Don't fetch replays for every triaged issue — only
the ones the user asks to dig into.
Lead with a one-line headline ("3 new issues in last 24h, 1 spike, 5 active high-impact"). Then a short table sorted by your chosen signal:
| Issue | First seen | Users | Sessions | Sample message | Suggested action |
|---|---|---|---|---|---|
| ... | 2h ago | 142 | 198 | TypeError ... at checkout.js:42 | Investigate |
| ... | spike | 67 | 89 | Network request failed | Watch — likely transient |
| ... | 3d ago | 12 | 12 | chrome-extension:// timeout | Suppress (extension noise) |
For each, suggest one of: investigate (investigating-error-issue), assign
(error-tracking-issues-partial-update), suppress (suppressing-noisy-errors),
merge (grouping-noisy-errors), or resolve if it's already known fixed.
properties.$lib_version (or properties.$exception_releases when the
SDK is configured to populate it), present them grouped — a rollback decision
rests on the cluster, not any one issue.sessions or occurrences.posthog:inbox-reports-list), check it first — PostHog
may have already curated the most actionable issues so you avoid re-deriving them./error_tracking/<id>) for each row so the user can jump
straight to the issue page if they want to drill down themselves.