triaging-error-issues

Ranks PostHog error tracking issues by users affected and recency for daily triage reviews.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill triaging-error-issues
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: triaging-error-issues
Source: https://github.com/PostHog/posthog-foss/tree/main/products/error_tracking/skills/triaging-error-issues
Command: npx skills add https://github.com/PostHog/posthog-foss --skill triaging-error-issues

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Engineering teams with hundreds of active error tracking issues struggle to identify which ones deserve attention during daily or on-call reviews. This Skill turns a vague question like "what's broken?" into a short, prioritized list of new, spiking, or high-impact issues with suggested next actions.

Core Features & Use Cases

  • Prioritized issue ranking: Queries PostHog error tracking issues ordered by distinct users affected, first-seen recency, or occurrence spikes over a configurable time window.
  • Noise filtering: Separates genuinely new issues and regressions from flat-volume background noise, bot-only traffic, and browser extension errors.
  • Context enrichment: Pulls sampled exception events with stack frames, URLs, and session IDs for top candidates, and links to session replays for deeper investigation.
  • Use Case: During a morning on-call handoff, ask for the top errors from the last 24 hours and receive a table of issues ranked by users affected, each with a sample stack frame and a suggested action such as investigate, assign, suppress, or merge.

Quick Start

Ask the assistant to show the top new and high-impact PostHog error tracking issues from the last 24 hours with suggested actions.

Frequently Asked Questions about triaging-error-issues

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage PostHog error tracking issues each morning?

Query the issues list with a 24-hour date range ordered by users affected, then run a parallel query ordered by first_seen to catch new issues. Filter out flat-volume noise and present the top items with sample stack frames and suggested actions.

How do I find new errors after a deploy in PostHog?

List active issues ordered by first_seen descending over a tight window like the last 24 hours. Issues whose first_seen falls inside the window are new; group those sharing a library version since one deploy often surfaces several related issues.

Should I rank errors by occurrences or users affected?

Rank by distinct users affected for user-facing apps, since one bot loop can produce many occurrences but only one user. For backend services without a real distinct_id concept, fall back to sessions or occurrences.

How do I filter server-side errors from browser errors in PostHog?

Use the library filter with values matching the SDK's $lib property, such as web for posthog-js or posthog-node, posthog-python, and posthog-go for server SDKs. This prevents server-side errors from drowning out browser issues in top-by-users lists.

When should I suppress an error issue instead of investigating it?

Suppress issues whose events all come from headless browsers, crawler user agents, or browser extensions, since they are noise rather than real user impact. Flat-volume long-running issues are also candidates for suppression rather than repeated triage.