An AI agent that runs a weekly product health check on PostHog's MCP server and writes the report itself.
Watch the demo · Open the interactive dashboard · Built on the PostHog MCP
product-health-monitor-config.md: the complete build spec. Architecture, MCP connection, agent settings, design decisions from live runs, the read-only governance rule, and the scheduled trigger.prompts/agent-instructions.md: the agent's Instructions field, verbatim. Behavior, triage framework, thresholds.prompts/skill-product-health-report.md: the full skill, verbatim. Every query and every step of the procedure.examples/: screenshots from a live run against a seeded demo project.
 |
 |
 |
 |
The run shown: the agent detected a channel-specific acquisition break (one channel down 94 percent while others held), separated it from a live checkout bug, triaged three errors into RESOLVE, SUPPRESS, and ROUTE with stack-trace-grounded reasons, and closed with three priority actions. Data is seeded demo data.
A dashboard tells you what you knew to ask. An MCP server gets at what you didn't.
A dashboard is patient. It waits for you to know the question. You see a dip in a funnel, then the work is yours: open a new insight, split by platform, scrub session replays, hold timestamps in your head. Every new question is another click. An API does not rescue you either, because you would have to script the whole investigation in advance, and you cannot script for a problem that only showed up yesterday.
PostHog's MCP server changes the shape of the work. It turns PostHog into something you can ask. You pose one question and the agent does the heavy lifting. It runs a query, reads the result, and decides the next step, while keeping you in the loop for anything that matters.
I learned this firsthand. I connected the MCP to Claude and asked one thing: something looks off with conversions, can you investigate? The agent found the pricing-to-checkout-to-purchase funnel on its own and ran it. 40 users hit pricing, 24 reached purchase. It broke the funnel down by browser without being asked and found Safari converting at 30 percent against Chrome's 70. It queried the checkout error log for Safari in the same window, found five PaymentSheet initialization failures, confirmed every one was Safari, and narrowed the affected cohort. Then it handed me a hypothesis: the payment integration is broken on one browser, and it is dragging the whole funnel down. Nine tool calls, one question. No human pre-wrote that chain, and no single dashboard view holds it.
That investigation was reactive. I only asked because something already looked wrong. So I asked a better question. What if I never had to notice first?
The Product Health Monitor is the answer. It runs the investigation on a schedule, before anyone opens PostHog.
Once a week, the agent connects to PostHog over MCP and runs a full health check:
- Pulls the core funnel, the conversion events, the acquisition channels, and the error backlog.
- Computes week-over-week movement on every metric and flags what crossed a threshold.
- Triages every live error into resolve, suppress, or route.
- Builds a self-contained interactive dashboard: a red, yellow, or green status banner, an executive summary, a metrics table, a 14-day trend chart, channel breakdowns, a conversion funnel, the triaged errors, and three priority actions.
- Emails a plain-text summary with a link to the dashboard, so the health read lands in your inbox without a login.
One agent. One skill. One schedule.
- Watch the demo (about 80 seconds) shows the agent running the check and building the dashboard end to end.
- Open the interactive dashboard to explore the output of one run, charts and funnel included.
On its first scheduled run, the monitor returned RED. Here is what it caught, all from live PostHog queries:
- Signups down 40 percent week over week, 169 to 101.
- The cause was one channel. Facebook collapsed 94 percent, 54 signups to 3, while Google, direct, and Twitter held. A drop this channel-specific points to a broken campaign or tag, not falling demand.
- A checkout TypeError reading
paymentMethodoff an undefined object on the live checkout page, hitting real users across browsers. Bucket: resolve, critical. - A Stripe payment webhook timing out at 30 seconds, server-side. Bucket: route, to the payments team.
- A ResizeObserver browser warning, 60-plus occurrences, no user impact. Bucket: suppress.
Three findings, three buckets, three priority actions. The kind of read a product team or a customer success manager wants on a Monday morning without doing the digging.
A note on the data: this runs against a demo project I instrumented and seeded with 14 days of realistic product data, so the agent could be exercised end to end. The queries, the triage, and the dashboard are all real. The numbers come from real queries against that project.
PostHog frames the parts well. Tools and skills cover the what; signals cover the when. This agent has both.
The what is a single skill that defines the full procedure: which queries to run and in what order, how to compute week-over-week from a clean window, how to triage each error, and how to build the dashboard as inline SVG and HTML so the visuals render anywhere.
The when is a schedule. The agent fires on its own each week, runs the skill, and delivers. No prompt required.
The connection is PostHog's official MCP server (mcp.posthog.com/mcp), authorized over OAuth, with access to trends, funnels, HogQL, and error tracking. The agent is read-only by design. It investigates and reports. It does not change anything in PostHog.
The three buckets are not mine. They come from PostHog's own study of how AI agents clear an error backlog. Their team reviewed a month of MCP-driven triage across 6,124 errors and found the actions sorted cleanly into three.
| Bucket | What it means | The move |
|---|---|---|
| Resolve | A real bug in application code | Fix it |
| Suppress | Known noise: browser quirks, third-party warnings, no user impact | Silence it so it stops masking real signal |
| Route | Someone else's problem: a payments or infrastructure failure | Send it to the right team |
Agents resolved 4,063 of those errors and suppressed 1,751 more. The lesson underneath, in PostHog's words, is that errors are starting points, not endings. This monitor uses the same three buckets, and it ends every error on an action rather than a verdict.
PostHog calls its next chapter self-driving products: software that surfaces answers, acts on them inside guardrails you set, and takes the data as its starting point rather than a human prompt. The Product Health Monitor is a small, working expression of that idea aimed at one job. It does not wait to be asked. It watches, decides what matters, and tells you.
It also lines up with how PostHog's customer success team already works. Their playbook is to watch usage so customer health does not slide into the red, to act early when it does, and to treat automated insights as the start of an investigation rather than the final word. This agent produces exactly that: an early, color-coded health read that points you at the next move and leaves the judgment to a human.
The direction is not mine. PostHog has been clear about where it is heading. This is one small build pointed that way.
- PostHog MCP (
mcp.posthog.com/mcp) for all data: trends, funnels, HogQL, and error tracking. - Gumloop for the agent runtime, the skill, and the schedule.
- Claude Opus for the live investigation and the dashboard build.
- Inline SVG and HTML for the visuals, so the dashboard is self-contained and renders without dependencies.
No application code. The agent writes the dashboard on each run.