Learn Error Tracking with your agent

Teach me PostHog Error Tracking using my own product and PostHog project.

Inspect its existing PostHog instrumentation, then create a custom learning path based on its real issues, grouping, queries, and alerts. Teach one concept at a time and give me small, safe exercises.

Use the PostHog Error Tracking docs at https://posthog.com/docs/error-tracking.md as the source of truth.

Don’t change the project unless I explicitly ask. If you can’t access the project, tell me what context you need.

Teach me PostHog Error Tracking using the exceptions in my app. Explain how exceptions become issues, and how grouping and source maps decide what I see. Help me check that my exceptions reach PostHog with readable stack traces, and fix any issues that are grouped wrong.

Use my code and PostHog data. Teach one concept at a time with a small exercise, and review my answer before continuing. Use https://posthog.com/docs/error-tracking.md as the source of truth.

Don’t change my project without asking. If context is missing, ask for it.

Teach me how to query PostHog exceptions alongside the rest of my data. Explain the keys that join an exception to people, sessions, and accounts. Help me find which issues hit my most valuable accounts, and which ones stop people from finishing what they started.

Use my code and PostHog data. Teach one concept at a time with a small exercise, and review my answer before continuing. Use https://posthog.com/docs/error-tracking.md as the source of truth.

Don’t change my project without asking. If context is missing, ask for it.

Teach me how to automate PostHog Error Tracking. Explain assignment rules, alerts, and the scouts that report on errors. Help me route issues to the team that owns each part of my code, alert on regressions and spikes, and turn on the error scouts.

Use my code and PostHog data. Teach one concept at a time with a small exercise, and review my answer before continuing. Use https://posthog.com/docs/error-tracking.md as the source of truth.

Don’t change my project without asking. If context is missing, ask for it.

Rank my error tracking issues from the last 7 days by the total MRR of the accounts that hit them, with the exceptions, accounts, and affected users for each. Then tell me which issue to fix first and why. If my accounts don't have an MRR property, rank the issues by affected accounts instead and tell me how to add MRR with warehouse properties.

Build me a funnel over the last 7 days, counted by unique sessions, with a 1-minute conversion window. Step 1 is $exception where $lib is web. Step 2 is any event that shows the person kept going: a $pageview, an $autocapture event, or one of my app's named events, like stay_viewed. If autocapture is off, the named events are the main signal. Break it down by $exception_issue_id. Then tell me which issues have the highest drop-off among issues with at least 100 sessions.

Find session recordings from the last 7 days that include a $exception event from the error tracking issue named [issue name]. List the 5 most recent with links, and tell me what the person did just before the error.

List the error tracking issues that hit users in the account [account name] in the last 30 days. For each issue, show how many of their users it hit and how many exceptions it fired, sorted by users.

Use my synced support tickets table to find tickets from the last 30 days that contain a PostHog replay link. Take the session ID from each link and check whether that session had a $exception event. List the tickets that did, with the exception type and message.

List the people who hit the error tracking issue named [issue name] in the last 30 days, with each person's email and how many exceptions they had.

Build a trend over the last 14 days, counted by unique sessions. Series A is $exception and series B is $pageview. Set the formula to A / B * 100 and break it down by $feature/my-flag-key. Tell me whether any variant has a higher error rate than control.

Build a trend over the last 30 days, counted by unique sessions. Series A is all events. Keep web and mobile apart. For web, series B is $exception where $exception_handled is false. For mobile, series B is $exception where $exception_level is fatal. Set the formula to (A - B) / A * 100 to show the share of sessions without an unhandled exception or crash, and tell me which days were lowest.