Agent skill · posthog
triaging-warehouse-sync-tickets
Debug a customer's data warehouse source, schema, or table from a support ticket, using PostHog's own production data. Use when a ticket says a warehouse table is stale, empty, stuck, duplicated, missing rows, or failing to sync, and you need the real state of the sync rather than the customer's description. The customer is on a team your MCP session cannot reach, so every answer comes from execute-sql with a connectionId set to a direct-connect source over PostHog's live production databases, which hold all customers' data. Covers region detection (US vs EU), the Production Postgres connection (externaldatasource / externaldataschema / externaldatajob / datawarehousetable), the Production ClickHouse connection (log_entries, app_metrics2), cross-region access through posthog-connection-call, why the external-data-* product tools silently answer from your own project instead, and how to end with one recommended action plus who can run it. Internal only: every query returns another customer's data.
What it needs
About 12k tokens when loaded.
What this skill does
Triaging warehouse sync tickets A support ticket tells you what a customer sees. This skill tells you what actually happened. The output is a diagnosis plus one recommended action for the support agent. You are a PostHog employee working a ticket for a different customer's team. That single fact drives everything below. The one way you read customer data: execute-sql over a direct-connect source PostHog's own project holds direct-connect warehouse sources pointed at the live production Postgres and ClickHouse databases. Those databases hold every customer's rows. So: That is the whole access model. connectionId is what makes the query run against production instead of your own project's catalog. The connections are raw database connections, not team-scoped views, so a teamid filter is the only thing separating one customer from another. This is confirmed: a GROUP BY teamid over logentries returns hundreds of teams. Production Postgres holds the sync control plane: posthogexternaldatasource, posthogexternaldataschema, posthogexternaldatajob, posthogdatawarehousetable, plus posthogteam / posthogorganization / posthoguser for identifying who filed the ticket. Production ClickHouse holds the runtime evidence: logentries for per-run pipeline logs, and appmetrics2 for success, failure, and row counters. Together those answer every question a warehouse sync ticket raises. Step 1 shows how to open both, in either region. Do not reach for the product tools external-data-sources-list, external-data-schemas-list, external-data-schemas-retrieve, external-data-sources-retrieve, and every other external-data- tool read the MCP session's own project. So does execute-sql with no connectionId. None of them can see the customer. They also do not error when you point them at a ticket. They return PostHog's own sources, with real ids, real statuses, and real error strings. That output is indistinguishable from an answer until someone notices the numbers describe the wrong company. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills posthog/triaging-warehouse-sync-tickets