product-health-check

Give one combined picture of the product's health over a period, from Sentry (errors), PostHog (usage) and Stripe (payments), and point at what needs attention. It only reads.

Arguments

• A period (optional): 24h by default, or 7d, 30d.
• A focus (optional): a release, a feature or a customer segment.

Flow

1. Check what is connected. See which of the sentry, posthog and stripe MCP servers answer. For each one that needs a sign-in, say so and go on with the rest; with none connected, stop.
2. Fix the scope. Confirm the organization and project in each service and that they are production (for Stripe: live mode, unless the user asked for test mode). Use the same period everywhere, and the same length of time just before it as the baseline.
3. Errors (Sentry): new issues, regressed issues and the issues with the most events and affected users in the period; the release each one first appeared in; the crash-free rate when the project reports it.
4. Usage (PostHog): active users, sign-ups and the product's main conversion or activation metric against the baseline, following the querying-posthog-data skill for queries. If the project has no obvious main metric, ask which one matters instead of picking one.
5. Payments (Stripe): successful and failed payment counts and the failure rate against the baseline, the most common decline or error codes, new and cancelled subscriptions, and open disputes.
6. Connect them. Line the three up on one timeline with releases and feature-flag changes. Where a metric moved, look for an error or a payment failure that started at the same time; follow the investigate-metric skill for a drop worth explaining and the sentry-debug-issue skill for an error worth fixing. Call a link a cause only when the timing and the affected users match.
7. Give the report. Create or change nothing in any service.

Report

• Headline: healthy, needs attention or incident, in one sentence, with the period and the services covered.
• Needs attention, most urgent first: what changed, by how much against the baseline, since when, who is affected, and the suggested next step.
• Errors, usage and payments: the figures of steps 3 to 5, each with its baseline.
• Likely connections between them, each marked confirmed or possible.
• Not covered: services not signed in, metrics that were unavailable, and figures that are sampled.