ClaudeSuperPower

resolving-ingestion-warnings

Skill

Diagnoses and resolves PostHog ingestion warnings — problems recorded while ingesting events (dropped events, rejected person merges, oversized payloads, invalid data). Use when a user asks why events are missing, dropped, or undercounted, why identify/alias calls don't work or accounts stay duplica

Install

git clone https://github.com/PostHog/ai-plugin.git ~/.claude/skills/resolving-ingestion-warnings

What is resolving-ingestion-warnings?

Diagnoses and resolves PostHog ingestion warnings — problems recorded while ingesting events (dropped events, rejected person merges, oversized payloads, invalid data). Use when a user asks why events are missing, dropped, or undercounted, why identify/alias calls don't work or accounts stay duplicated, why person or group properties aren't updating or profiles look inflated, why recordings have gaps, heatmaps are empty, LLM token counts are missing, why cookieless events vanish, or whenever `posthog:ingestion-warnings-list` returns results. Explains severity triage (error = dropped, warning = modified, info = intentional) and routes all warning types — size limits and enrichment, merges and distinct IDs, `$process_person_profile`, timestamps, cookieless, heatmaps, transformations, session replay — to per-issue reference files with code-level causes and per-SDK fixes.

What this can do

Capabilities declared in this component's own frontmatter — not inferred.

Inherit all session tools

Declares no tool restrictions — inherits every session tool

~220 tokens of context used while enabled, before you invoke anything

Documentation

README · ~5 min read

Resolving ingestion warnings

Ingestion warnings record problems PostHog hit while ingesting a project's events. They are the first place to look when events are missing, counts are lower than expected, or identify/merge calls don't behave.

Workflow

  1. List the warnings: call posthog:ingestion-warnings-list (defaults to the last 24h; widen with since: '-7d', narrow with severity or type). Each entry has a count, a sparkline, and recent samples with the affected event_uuid / distinct_id / person_id / group_key.
  2. Triage by severity — it encodes what happened to the data:
    • error — the event or update was dropped. Data loss; fix these first.
    • warning — ingested, but modified or partially rejected.
    • info — informational, or an intentional, team-configured drop.
  3. Route by type using the table below. Where a references/fixing-*.md file exists, read it — it has the full diagnosis and per-SDK fixes; load only the file you need.

Reviews

Log in to leave a review.

No reviews yet — be the first.

Explore related

Other things in this space — across every part of the ecosystem, not just skills.

Skillssimilar to this one

All skills