diagnosing-endpoint-performance

Diagnose slow or expensive PostHog endpoints and recommend cache, materialisation, or query fixes.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

PostHog endpoints can become slow, time out, or hit cost caps as data grows, and it is hard to know whether the fix is a cache TTL change, materialisation, or a query rewrite. This Skill walks a single named endpoint through a structured decision tree and produces one concrete, justified recommendation.

Core Features & Use Cases

  • Cache TTL analysis: Inspects data_freshness_seconds and call patterns to determine whether bumping the cache TTL is the cheapest fix.
  • Materialisation evaluation: Checks eligibility via materialisation preview and status tools, explains rejection reasons, and flags which variables become required for callers.
  • Query rewrite guidance: Maps materialisation rejection reasons (JOINs with variables, cohort breakdowns, unbounded scans) to concrete HogQL rewrites, with an optional feature-gated AI rewrite accelerator.
  • Use Case: A user says "monthly_active_users is timing out." The Skill fetches the endpoint config, finds the TTL at the 15-minute floor and materialisation eligibility confirmed, then recommends bumping the TTL to 3600s or enabling materialisation.

Quick Start

Ask the agent to diagnose why your named PostHog endpoint is slow or hitting the cost cap and recommend a fix.

Frequently Asked Questions about diagnosing-endpoint-performance

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

FAQPage Schema
How do I fix a slow PostHog endpoint?

Start by checking the endpoint's cache TTL via data_freshness_seconds, since bumping it from the 900-second floor is the cheapest fix. If freshness requirements rule out caching, evaluate materialisation eligibility or rewrite the underlying query.

When should I materialise a PostHog endpoint?

Materialise when the endpoint is eligible per the materialisation preview, callers can tolerate staleness equal to the refresh interval, and filter shapes are predictable. Note that callers must then pass all materialised variables or requests are rejected.

Why is my endpoint not eligible for materialisation?

Common rejection reasons include cohort breakdowns, compare mode, JOINs combined with variable filters, unbounded scans without time-window variables, and non-deterministic functions. The materialisation preview tool returns the specific rejection reason to guide a rewrite.

How do I check which endpoint version is being called?

Use endpoint-versions to list all versions and their last_executed_at timestamps. Only the latest version runs by default; older versions run only when a caller pins ?version=N in the request URL.

What are the limitations of endpoint materialisation?

Materialisation adds storage and refresh compute costs, introduces staleness equal to the refresh interval, and requires callers to pass all materialised variables. Some query shapes, like the OR optional-variable idiom, have no equivalent materialisable rewrite.