See what we're building
Pineapple on pizza

No data available

Feature ownership
Members

Roadmap

What we're building

  • iOS and Android native support

    Capture exceptions on native platforms

    Project updates

    No updates yet. Engineers are currently hard at work, so check back soon!

Goals

Q3 2026 Objectives

Onboarding - Setup & configuration - (Driver: Aleksander Błaszkiewicz)

Error Tracking is only useful when it is configured correctly. We want the Wizard to become the guided setup path that makes onboarding simpler, faster, and harder to get wrong. What we'll ship:

  • Wizard-guided symbolset uploads for native SDKs
  • Wizard-guided symbolset uploads for mobile SDKs
  • Wizard-guided alerting setup
  • Wizard-guided assignment rules setup
  • Common suppression rules
  • Wizard-guided Error Tracking setup across supported platforms

Native alerting - Stateful notifications - (Driver: Catalin Irimie)

Alerting should reflect the full issue lifecycle, not just fire-and-forget notifications. We want alerts that can update users as issues are created, spike, get analyzed, are fixed, or are resolved. What we'll ship:

  • Thread-like notifications when possible (Slack, Discord)
  • Natural language alert setup
  • Email notifications

Release management - Codebase context - (Driver: Aleksander Błaszkiewicz)

Error Tracking should connect runtime exceptions back to the code that caused them. We want to make it easier to find the original source file, understand when an error was introduced, and assign issues to the right code owners. What we'll ship:

  • Stable JavaScript chunk IDs to avoid unnecessary reuploads
  • Unified release, app name, and app version properties
  • Better GitHub integration to link stack frames to source code
  • Pull request and author attribution for newly introduced errors
  • Stretch: Source code context for stack frames from GitHub / GitLab

Issue enrichment - PostHog context - (Driver: Hugues Pouillot)

Error Tracking is most powerful when it includes context from the rest of PostHog. We want to bring more product, user, log, and AI context into each issue so users and agents can debug faster. What we'll ship:

  • Signal reports attached to issues
  • Add error tracking measures on Experiments
  • Logs context on issues
  • AI Observability context on issues

User interface - Issue details & filtering - (Driver: Hugues Pouillot)

The issue list and issue details pages should make triage and debugging easier. We want a clearer, more flexible interface that works well across screen sizes. What we'll ship:

  • A more extensible issue details layout that supports reports, tasks, and mobile views
  • Improved issue list filtering

SDK feature parity - Cross-SDK consistency - (Driver: Catalin Irimie)

Error Tracking capabilities should be consistent across SDKs. We want users to get reliable behavior for rate limiting, suppression rules, exception steps, source context, and remote config no matter which supported SDK they use. What we'll ship:

  • Error Tracking support for the Java SDK
  • Normalized frame and exception ordering
  • Source context for native SDKs
  • Stretch: Standardized rate limiting

Handbook

What the Error Tracking team does

  • Exception capturing (autocapture, manual)
  • Exception querying
  • Exception management (assigning, merging, alerting)

How to work with the Error Tracking team

Reach out in our Slack channel #team-error-tracking

Who are we building for?

Primary (building for, churn indicates product failure)

Product & Growth Engineers

  • JTBD: Get notified when new issues happen / escalate, identify impact, have context to fix
  • Why prioritize: champion persona who adopts ET

Founders

  • JTBD: Same as above but specifically want to know when early users face any exception
  • Why prioritize: YC/high-potential, core to get-in-first strategy at product-led startups shipping multiple times/week

Who we somewhat support (product will fully support them in time but we’re ok with churn in the short term)

DevOps/SRE Engineer

  • JTBD: Cost control, release tracking, cross-service correlation, custom grouping for high-volume services
  • Why: we will ideally support these use cases but do not have full coverage right now (missing releases UI, automatic request ID instrumentation, complex snoozing / alerting rules based on thresholds, logs integration)

AI/ML Engineer (emerging)

  • JTBD: Track LLM quality degradation, hallucinations, cost explosions (non-traditional "exceptions")
  • Why: might churn to specialized tools while we work on integrating deeper with AIO

Support Engineer

  • JTBD: Quick context on user-reported errors to triage severity, share details with product engineers
  • Why: not a regular user but happy to support requirements that are a subset of the primary persona

Who we’re not building for (do not expect the product to be of great value)

Product Managers

  • JTBD: Understand which bugs block conversion/revenue, help prioritize by business impact

Vibe coders

  • JTBD: Be informed of improvement to metrics from automatic bug fixes
  • Why: Engineers in our ICP companies (high-growth startups, and those who could become that) generally do not vibe code their products