PostHog Usage Anomaly Detector

Step 1 — The Fetcher

Code-only

Queries PostHog API for daily usage metrics — event counts, unique users, session durations, and feature usage across the baseline window. Pulls both current day and historical baseline data for statistical comparison.

Step 2 — The Assembler

Code-only

What does The Assembler actually decide? Computes statistical baselines using rolling averages and standard deviation for each tracked metric. Identifies anomalies where current values deviate beyond the configurable threshold (default 2 standard deviations). Calculates anomaly magnitude and direction (spike or drop).

Step 3 — The Analyst

Tier 2 Classification

This step exists because raw data alone is not enough. Performs probable cause analysis for each detected anomaly: correlates with deployment timestamps, feature flag changes, marketing campaigns, and day-of-week patterns. Classifies anomaly severity (INFO, WARNING, CRITICAL) and type (organic, deployment-related, external, seasonal).

Step 4 — The Formatter

Tier 3 Creative

Without this step, upstream analysis sits idle. SILENT when no anomalies detected — no Slack noise on normal days. When anomalies are found: Slack alert with anomaly details, probable causes, and recommended investigation steps. Optional Notion log for anomaly history tracking.Synthetic IDs passed the pipeline logic but failed on the CRM write. We wasted 2 hours debugging the wrong service.