Docs

PostHog Error Tracking: What to Track

PostHog now bundles error tracking with product analytics — what event and stack trace data to capture so crashes join your behavioural data.

Performance

PostHog has folded error tracking into the same platform as its product analytics, session replay and feature flags, which changes a workflow most teams have lived with for years: errors in one tool, behaviour in another, and a manual, usually-skipped step to connect the two. That gap matters more than it looks. A crash or unhandled exception is not just an engineering problem — it’s a product event. A checkout that throws an error for 2% of users on one app version is a revenue leak that only shows up if someone cross-references a Sentry-style error log against a conversion funnel, and in practice, almost nobody does that consistently.

The failure mode teams hit without unified tracking is treating errors and analytics as separate universes. Engineering sees “500 exceptions this week” with no sense of how many users or how much revenue that touched. Product sees a conversion drop with no idea an error caused it. Bundling error capture with the same user and session identifiers already used for product analytics closes that gap by default, rather than requiring a data warehouse join that someone has to remember to build.

Data Points to Track

  • Exception type, message and stack trace, captured with source maps or symbolication so the trace points at real code, not minified output
  • User and session ID, shared with standard product analytics events so an error can be tied to the session it interrupted
  • App version, OS and device context, so a spike can be isolated to a specific release or platform rather than treated as global noise
  • Preceding event sequence, the last few product events before the error, showing what the user was doing when it happened
  • Error frequency per user, distinguishing a one-off glitch from a user who is hitting the same failure repeatedly
  • Business context at time of failure — cart value, plan tier, or feature flag state — so severity can be judged by impact, not just volume

Setup Steps

  1. Enable the PostHog error tracking SDK alongside your existing product analytics capture, rather than running a separate error tool in parallel.
  2. Upload source maps or debug symbols for every release so stack traces resolve to real file and line numbers instead of obfuscated code.
  3. Confirm the same distinct/session ID is used across error events and product events — this is what makes the join automatic instead of a manual export.
  4. Group errors by fingerprint, not raw message string, so the same underlying bug reported with slightly different messages counts as one issue.
  5. Route high-severity, high-revenue-impact errors into alerting based on the business context properties, not just raw exception count.

Actionable Insights

With errors and product events living in the same dataset, you can answer the question that actually matters: does this crash cost us users or revenue, or is it cosmetic? A high-frequency error on a screen nobody converts from is a backlog item; a low-frequency error that always precedes cart abandonment is a fire. Ranking errors by downstream funnel or revenue impact — not raw count — is only possible once the error stream and the behavioural stream are the same stream, which is the actual point of bundling the two rather than running them as separate tools that happen to share a dashboard.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert