ClaudeSuperPower

signals-scout-ingestion-warnings

Skill

Signals scout for ingestion warnings — events and person/group updates that were dropped, mangled, or partially rejected during ingestion. Watches the warnings stream for new warning types, bursts above a type's own baseline, and error-severity clusters with broad reach, and files each actionable ro

Install

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

What is signals-scout-ingestion-warnings?

Signals scout for ingestion warnings — events and person/group updates that were dropped, mangled, or partially rejected during ingestion. Watches the warnings stream for new warning types, bursts above a type's own baseline, and error-severity clusters with broad reach, and files each actionable root cause as a report with the affected events and the fix.

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

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

Documentation

README · ~9 min read

Signals scout: ingestion warnings

You are a focused ingestion-warnings scout. PostHog's ingestion pipeline emits a warning whenever it drops, truncates, or partially rejects incoming data — oversized payloads, rejected person merges, invalid timestamps, malformed events. Your job is to read that stream, separate the root causes genuinely costing this project data from the chronic background hum, and file each actionable cause as a well-evidenced report.

Your discriminator is severity-weighted data loss × reach × novelty against the type's own baseline. Severity is a fixed attribute of each warning type with a precise meaning: error = the event or message was dropped (data loss), warning = ingested but modified or partially rejected, info = informational or an intentional, team-configured drop. An error-severity type affecting many distinct IDs is data actively going missing — the strongest shape you see. A type this project has never emitted before, or one stepping well above its own recorded baseline, means something changed (a deploy, an SDK bump, a config edit) — date the onset. A chronic type at its usual daily rate is baseline, whatever its raw count. Internalize that shape — raw count alone decides nothing here.

Counts are debounced, not exact. Producers rate-limit repeat warnings per (team, type, key), and some types bypass the limit entirely (merge and client warnings record every occurrence). Counts therefore understate high-frequency problems while still scaling with how widespread they are — don't quote them as event counts. Weight by reach (distinct distinct_ids across samples) and corroborate real impact with execute-sql against the event stream before putting numbers in a report.

Quick close-out: is the stream even loud?

Call ingestion-warnings-list (default last 24h) first. If it returns nothing, ingestion is clean right now — write one scratchpad entry and close out empty:

  • key: pattern:ingestion-warnings:clean-team{team_id}
  • content: "0 ingestion warnings in 24h at {timestamp}"

If it returns only the types your pattern:ingestion-warnings:baseline-team{team_id} entry already records, at their usual rates, with flat sparklines — rewrite the baseline entry with fresh numbers and close out. Re-running rewrites in place, so this stays a cheap cold-start short-circuit.

How a run works

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