exploring-endpoint-execution-logs

Inspects execution log entries for a single PostHog endpoint to diagnose failures and cache behavior.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When a PostHog endpoint fails, returns unexpected rows, or misses cache, you need to know what happened during its runs. This Skill reads the per-run execution log entries stored in PostHog's log_entries store so you can pinpoint errors, versions, and execution paths without guessing.

Core Features & Use Cases

  • Failure diagnosis: Filter logs by ERROR level to read the error token (e.g. ResolutionError, HogVMException) and the execution path where the run broke.
  • Cache and row analysis: Search key=value tokens like cache=miss or compare rows= and version= across runs to spot regressions after a version bump.
  • Trend aggregation: Run SQL against log_entries to compute error rates or run counts over time for a specific endpoint.
  • Use Case: A user says "weekly_signups started erroring this morning." The Skill pulls recent ERROR logs, finds version=5 failing with ResolutionError on the inline path, confirms v4 ran fine, and recommends reviewing the v5 query or rolling back.

Quick Start

Ask the agent to show the recent execution logs and errors for your endpoint by name, for example "why is my endpoint weekly_signups failing?"

Frequently Asked Questions about exploring-endpoint-execution-logs

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

FAQPage Schema
How do I check why my PostHog endpoint is failing?

Query the endpoint's execution logs filtered to ERROR level. Each failed run logs one entry with an error token (e.g. error=ResolutionError) and the execution path, telling you what broke and where.

How can I tell if my endpoint is hitting the query cache?

Search the endpoint's execution logs for the cache token, such as cache=miss or cache=hit. Each run's log entry records whether the query result cache was used, except on ducklake paths where the token is omitted.

What information does each endpoint execution log entry contain?

Each run emits exactly one entry with key=value tokens: path (materialized, inline, ducklake), cache (hit/miss), duration_ms, rows, version, and error on failures. Level is INFO on success and ERROR on failure.

Can I aggregate endpoint error rates over time with SQL?

Yes, query the log_entries table with log_source='endpoints' and log_source_id set to the endpoint UUID from endpoint-get. Group by day and level to compute run counts and error rates over a period.

How far back do endpoint execution logs go?

Execution logs are retained for approximately 90 days due to the log_entries TTL. Runs older than that will not appear in the log viewer or SQL queries.

When should I use execution logs versus endpoint performance diagnosis?

Use execution logs to answer what happened during a run and why it failed. Use performance diagnosis when deciding whether to materialize the endpoint or change cache TTL, since that reasons over config and query_log cost metrics.