analyzing-experiment-query-performance

Query and interpret PostHog experiment query-performance data from staff-only debug endpoints.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill analyzing-experiment-query-performance
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: analyzing-experiment-query-performance
Source: https://github.com/PostHog/posthog-foss/tree/main/.agents/skills/analyzing-experiment-query-performance
Command: npx skills add https://github.com/PostHog/posthog-foss --skill analyzing-experiment-query-performance

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Investigating slow or failing experiment queries in PostHog production requires pulling data from staff-only debug endpoints, and interpreting the results demands knowledge of exception codes, precompute skip reasons, and job states that are not documented elsewhere.

Core Features & Use Cases

  • Slowest query analysis: Pull the top 100 slowest experiment query groups from /api/debug_ch_queries/slowest_queries/ with filters for team, experiment, metric type, and exception code.
  • Precompute health monitoring: Check read/build success rates, failure codes, wasted spend on failed builds, and Postgres job states via precompute_overview.
  • Cache footprint inspection: Inspect preaggregation table partitions and TTL-driven growth via cache_health across prod-US and prod-EU regions.
  • Use Case: A user reports experiment queries timing out with error 159. Use this Skill to query the slowest_queries endpoint filtered by exception_code=159, identify the responsible team and metric type, and check whether precompute builds are failing.

Quick Start

Ask the assistant to check experiment query performance health in both US and EU regions over the last 24 hours using the precompute overview endpoint.

Frequently Asked Questions about analyzing-experiment-query-performance

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I investigate slow experiment queries in PostHog production?

Query the /api/debug_ch_queries/slowest_queries/ endpoint with a staff personal API key carrying the query_performance:read scope. Filter by team_id, experiment_id, metric_type, or exception_code to localize the slowest query groups, then project fields with jq.

What do ClickHouse exception codes 307, 159, and 241 mean for experiment queries?

Code 307 is TOO_MANY_BYTES from per-query read caps, 159 is TIMEOUT_EXCEEDED from hitting max execution time, and 241 is MEMORY_LIMIT_EXCEEDED from query-level OOM. Codes 202 and 164 indicate cluster issues rather than query problems.

Why does authentication fail with a 403 on the debug_ch_queries endpoints?

A 403 means the key lacks the query_performance:read scope, is a wildcard full-access key, or the account is not staff. The scope must be granted explicitly via the API since it is absent from the key-creation UI.

What does an empty precompute skip reason on a direct_scan read mean?

It means precompute was attempted but the data was not ready, so the read paid for both the build and a full events scan. This bucket should stay near zero and is the key signal for precompute regressions.

What are the limitations of the slowest_queries endpoint?

It returns only a top-100 duration ranking, so cheap-but-chatty query patterns are invisible. The hours parameter is clamped to 1-168, and longer lookbacks require querying query_log_archive directly via Metabase.