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.