PostHog Insights & Dashboards

PostHog Insights & Dashboards

Overview

An insight is a saved analytics query in PostHog — a trend, funnel, retention curve, or similar chart — that PostHog computes on demand. A dashboard groups several insights into one view, typically the thing a client-facing analyst screenshots for a report. For an MSP, this is the surface for answering "how is the client's product actually being used" and "is the error rate climbing" without opening PostHog directly.

This skill is read-only: it retrieves insights and dashboards that already exist. It cannot create, edit, or delete either.

Anti-triggers

• Creating, editing, or deleting an insight or dashboard — this plugin ships read-only at v1 by design; see GOVERNANCE.md, Tool permission tiers, for why. Build or change the insight in the PostHog UI directly.
• Feature flag or experiment status — use feature-flags-and-experiments.
• Raw event or cohort lookups — use cohorts-and-events.
• Auth, key scopes, or rate-limit behavior — use api-patterns.

Core Concepts

Insights come in several types — trends (metrics over time), funnels (step-by-step conversion), retention (cohort return behavior), paths, and others — each computed against the project's event stream. A dashboard is an ordered collection of insights with its own name and description; the same insight can appear on more than one dashboard.

Insight results can be served from a cached computation rather than recomputed on every request. Treat a result's timestamp as "as of," not as "live right now" — for a fast-moving metric during an incident, re-run the underlying query rather than trusting a cached dashboard tile.

API Patterns

The confirmed read tool family for this domain:

• dashboard-get — retrieve a single dashboard by ID
• dashboards-get-all — list dashboards in the connected project
• Insight run/read — execute or retrieve the result of a saved insight

This plugin exposes only these read tools. PostHog's own docs carry the exhaustive, versioned tool catalog: posthog.com/docs/model-context-protocol/tools.

Common Workflows

SOC analyst checking error-tracking before an escalation

A client reports intermittent failures. Before opening an incident:

1. dashboards-get-all to find the client's error-tracking or observability dashboard
2. dashboard-get on that dashboard to pull its current insight tiles
3. Run the relevant error-rate insight directly if the dashboard tile looks stale, and compare against the incident's reported timeframe

vCIO pulling usage trends for a QBR

Ahead of a quarterly business review, pull the metrics that support a renewal or expansion conversation:

1. dashboards-get-all to locate the client's product-usage or adoption dashboard
2. dashboard-get to retrieve its insights
3. Summarize month-over-month trend direction for the metrics the QBR deck needs — active users, feature adoption, retention — rather than dumping raw numbers

Post-deployment health check

After a client ships a release, confirm nothing regressed:

1. Retrieve the insight or dashboard tracking the release's target metric (error rate, conversion, latency-adjacent proxy metrics PostHog tracks)
2. Compare the post-release window against the prior period
3. Flag anything outside the client's normal variance for human follow-up — this skill reports, it does not remediate

Gotchas

• Read-only surface. There is no tool here to create or update an insight or dashboard, even to fix an obviously broken one.
• Cached results can lag. A dashboard tile's "last computed" time may be older than the question being asked; re-run the insight directly when recency matters.
• Large projects have many dashboards. Prefer a targeted lookup by name or ID over listing everything and scanning — dashboards-get-all returns every dashboard in the project, not just the relevant one.

Related Skills

• Feature Flags & Experiments — Flag and experiment status
• Cohorts & Events — Raw event and segment lookups
• API Patterns — Auth, scopes, and error handling