PostHog Handbook Library / Marketing

2,079 words. Estimated reading time: 10 min.

Error tracking

Auto TL;DR

At a Glance

This long page covers these main areas. The list is generated from the article headings, so it updates with every handbook rebuild.

  1. Elevator pitch
  2. The unique belief
  3. Who this is for
  4. Who this isn't for
  5. Messaging
  6. Message 1: Every error already knows the user
  7. Message 2: Drop Sentry, Bugsnag, or Rollbar
  8. Message 3: Triage errors by who they hit

Owner: Sara Miteva

Elevator pitch

PostHog Error Tracking captures unhandled exceptions from web, mobile, and backend code, groups them into issues, and surfaces them alongside session replays, logs, feature flags, and product analytics in the same platform. Source maps, auto-assignment, spike detection, "Fix with AI" prompts, and Slack / Linear / Jira / GitHub alerts all come built-in. Generous free tier, then usage-priced per exception.

Sentry has deeper error tracking features, more battle-tested SDKs, and more granular grouping. PostHog wins on context: every exception ties to the user who hit it, the session replay of the moment it broke, and the feature flag they were on. Customers pick PostHog when they want errors linked to product behavior, not when they want pure error-tracking depth.

The unique belief

PostHog's vision is a self-driving product: software that watches itself for bugs, ships the fixes, and prioritizes work by user impact, not error volume. That loop needs every error to know which user hit it.

Most error tracking tools give you a stack trace, a frequency count, and a release tag. They don't tell you which user hit the error, what they were trying to do, or whether it matters to the business. So engineers triage by error count instead of by user impact, and waste cycles on noisy errors that don't affect anyone real.

Every PostHog exception is a product event with the user attached. Click an error to watch the user's session replay. Filter exceptions by feature flag variant, plan tier, or revenue cohort. See the business impact next to the stack trace. PostHog Error Tracking is the only place where every error already knows who hit it, what they were doing, and whether it matters.

Who this is for

Who this isn't for

Messaging

Message 1: Every error already knows the user

Problem: Most error tracking tools give you a stack trace, a frequency count, and a release tag. They don't tell you which user hit the error, what they were trying to do, or whether it matters to the business. Engineers end up triaging by error volume instead of user impact.

Solution: Every PostHog exception is a product event with the user attached. Click an error to watch the user's session replay. Filter exceptions by feature flag variant, plan tier, or revenue cohort. See the business impact next to the stack trace.

Supporting features:

Message 2: Drop Sentry, Bugsnag, or Rollbar

Problem: Most teams pay for a standalone error tracker (Sentry, Bugsnag, Rollbar) and separate tools for everything else – analytics, replays, feature flags, logs. The error tracker sees the stack trace; the other tools have the user context. Engineers stitch them by hand every time something breaks.

Solution: PostHog Error Tracking replaces standalone error trackers – same SDK coverage on the languages that matter, with the user, session, replay, and flag context already attached. No CDP middleware, no identity stitching.

Supporting features:

Message 3: Triage errors by who they hit

Problem: Every error tracking tool surfaces errors by volume – the loudest exception wins the engineer's attention. But the loudest isn't always the most important. A high-volume bug in a free trial flow might matter less than a single exception breaking checkout for your top-paying customer.

Solution: Filter exceptions by user cohort, revenue, plan, or feature flag. See which issues are hitting your most valuable customers and fix those first. Roll back the flag that caused the spike from the same view.

Supporting features:

Battle cards

vs Sentry

Their approach: The 800-pound gorilla. Sentry is no longer just an error tracker; it now ships Error Monitoring, Logs, Session Replay, Metrics, Tracing, Profiling, Uptime Monitoring, and Cron Monitoring on one platform. AI suite "Seer": debugging agent, Autofix, AI Code Review, plus a Sentry MCP server. Event-based pricing with steep volume discounts – errors drop from $0.000363 to $0.000150 per event at 20M+. Free Developer plan (5K errors, 50 replays); Team starts at $26/mo + pay-as-you-go.

Where PostHog wins:

Honest concession: Sentry has deeper SDK coverage, more mature grouping, a longer mobile track record, and steep volume discounts that make them cheaper at 10M+ errors. We win on context, not coverage or cost-at-scale.

Also useful: PostHog vs. Sentry

vs Bugsnag and Rollbar

Their approach: Mid-market error tracking specialists. Rollbar positions as "code-first observability that connects errors, replays, and releases in one place" – session replay shipped, MCP integration, RQL query language, Root Cause Analysis AI shipped, Rollbar Resolve AI agent (opens PRs with fixes) coming soon. Free tier: 5K occurrences + 1K replays. SOC2 + ISO27001 certified. Bugsnag (SmartBear-owned) follows a similar mid-market specialist playbook, historically strong on mobile crash reporting.

Where PostHog wins:

vs Datadog

Their approach: Part of the broader Datadog observability platform – auto-grouping, real-time alerts, AI-powered insights, suspect commits. Session Replay (15 seconds before/after frontend errors) and Exception Replay (local variable capture on backend exceptions). Jira integration, Datadog On-Call. Built for SRE and platform engineering teams already invested in Datadog APM. Scales with Datadog's per-host platform pricing.

Where PostHog wins:

Objections

"Sentry has deeper SDK coverage, more mature grouping, and now ships session replay, logs, tracing, AI, and MCP too. What's actually different?"

Follow-up: Who would own this – platform/SRE engineering or product engineering? And is the use case pure error-tracking depth, or errors tied to user behavior?

Answer: Sentry has expanded dramatically beyond pure error tracking – replay, logs, metrics, tracing, profiling, AI/MCP. They've moved into Application Observability territory. If the team is platform-led and the use case is full-stack engineering observability with deep error coverage as the anchor, Sentry is the more direct fit and we should say so. PostHog's wedge is different: we don't try to win on observability features. We win on product analytics depth – funnels, retention, cohorts, paths, experiments, feature flags. Sentry has none of these despite their expansion. The comparison isn't "PostHog vs Sentry on error tracking" – it's "errors connected to engineering telemetry (Sentry's path) vs errors connected to product behavior (PostHog's)."

"We're a mobile-first app. PostHog's iOS error tracking has documented gaps."

Follow-up: What's the mobile breakdown – pure iOS, pure Android, or both? Which mobile crash features are non-negotiable?

Answer: Our iOS implementation has documented gaps. System frames aren't symbolicated, and Swift crashes appear as SIGTRAP without messages. The PostHog product page acknowledges it directly: "Even our team thinks Sentry is better if you need mobile support. For now!" Active development. If mobile crash reporting is the primary need, Sentry is the right tool today. Worth flagging: if the customer also needs product analytics on the same mobile app (session replay, feature flags, experiments, cohorts), PostHog still wins on that side – many teams run PostHog for product behavior and Sentry for mobile crashes today, then consolidate as our iOS support matures.

"Sentry is cheaper than PostHog at high volume – their volume discounts drop errors to $0.000150 each at 20M+."

Follow-up: What's your projected error volume next quarter and next year? Is error volume the primary cost driver, or do you need replay, analytics, and flags too?

Answer: True at very high volumes – Sentry's volume discounts are aggressive past 10M errors per month. If error volume is the primary cost concern and the customer doesn't care about the cross-product context, Sentry wins on price at scale. PostHog's value strengthens as the customer uses more of the platform. A useful reframe in the room: PostHog Error Tracking standalone vs Sentry standalone – Sentry wins on price at scale. PostHog Error Tracking bundled with replay + analytics + flags vs Sentry + LogRocket + Mixpanel + LaunchDarkly – PostHog wins on total stack cost easily.

"Customers say PostHog has noisy errors and false captures. Sentry's grouping is cleaner out of the box."

Follow-up: Is the concern signal quality (too many duplicates) or quantity (too many low-priority events)?

Answer: Honest: this came up in our customer research. PostHog's autocapture is broader than Sentry's, which gives more raw data but more noise. The grouping algorithm is still being improved, and the docs say so. Mitigations available today: custom fingerprinting rules, ingestion-time grouping rules, suppression rules, burst protection, before_send hooks for filtering, and spike detection with rolling baselines to separate real spikes from noise. If the team needs zero-tuning-required out-of-the-box quality, Sentry's grouping is more mature. If they want broader capture with manual tuning to get to signal, PostHog gets there with some setup work.

Canonical URL: https://posthog.com/handbook/marketing/how-we-position-and-sell/error-tracking

GitHub source: contents/handbook/marketing/how-we-position-and-sell/error-tracking.md

Content hash: b94d335047bbe828