What problem does it solve?
Developers working in the PostHog monorepo or PostHog-owned services need to ship application metrics (counters, gauges, histograms) into the PostHog Metrics product, but the correct path depends on the environment and pinned SDK versions, and wrong choices lead to silently dropped metrics or hand-rolled OTel plumbing.
Core Features & Use Cases
- Environment-based path selection: Decision table mapping monorepo Python (web, Celery, Temporal), Node services, and standalone services to the right SDK or OTel fallback.
- Version gate checks: Verifies posthog-python 7.23.0, posthog-node 5.43.0, and posthog-js ~1.399.0 before choosing the SDK path, with the OTel factory as fallback.
- Validation workflow: Confirms metrics actually arrive via MCP metric queries, the Metrics UI, or SQL against posthog.metrics, plus unit testing guidance.
- Use Case: Adding a counter for processed jobs in a Celery worker — check the pinned posthoganalytics version, record via posthoganalytics.default_client.metrics or the OtelInstrumentFactory twin, then verify arrival with a SQL query.
Quick Start
Ask the assistant to add a counter metric for jobs processed in the monorepo Celery worker and verify it arrives in posthog.metrics.