/insights-and-dashboards

name: "PostHog Insights & Dashboards"
description: >
  PostHog saved insights (trends, funnels, retention, and similar analytics
  queries) and the dashboards that group them into a single view. Read-only:
  running and retrieving existing insights and dashboards, not authoring
  them.
when_to_use: >-
  When looking up product-analytics results, usage trends, error-rate
  trends, or dashboard contents in PostHog. Use when: posthog insight,
  posthog dashboard, product analytics, usage trends, error tracking,
  weekly active users, funnel, retention, QBR dashboard, or analytics
  review.

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](../../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](https://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](../feature-flags-and-experiments/SKILL.md) — Flag and experiment status
• [Cohorts & Events](../cohorts-and-events/SKILL.md) — Raw event and segment lookups
• [API Patterns](../api-patterns/SKILL.md) — Auth, scopes, and error handling