Roadmap
Goals
Q4 2026 objectives
Objective 1: Increase signal, reduce noise (Owner: Hugues Pouillot)
Motivation: Customers should see one issue for each underlying problem and receive alerts only when aggregated activity requires attention.
What we'll ship:
- Improve fingerprinting by using source context – Hugues Pouillot
- Migrate the legacy fingerprinting algorithm to the new fingerprinting system – Hugues Pouillot
- Add a post-embedding grouping step – Hugues Pouillot
- Build an alert subscription model for post-ingestion processing – Hugues Pouillot
- Build pull-based alerting on PostHog Alerts – Hugues Pouillot
Objective 2: Automate issue triage (Owner: James Gill)
Motivation: Customers and agents should know which issues matter, who owns them, and what happened without completing manual triage.
What we'll ship:
- Add automatic issue assignment – James Gill
- Order issues by severity – James Gill
- Generate issue summaries – James Gill
- Evaluate tags for organizing and prioritizing issues – James Gill
Objective 3: Make Error Tracking first-class for agents (Owner: Aleksander Błaszkiewicz)
Motivation: Agents need a reliable way to set up Error Tracking and retrieve product, runtime, release, and source-code context when they investigate issues.
What we'll ship:
- Build a dashboard for agent usage across the Wizard, MCP tools, and skills – Aleksander Błaszkiewicz
- Highlight events with related Session Replay, traces, logs, and AI Observability context – Aleksander Błaszkiewicz
- Add agent hints that surface diagnostic issues in tool calls – Aleksander Błaszkiewicz
- Include release data on all PostHog events – Aleksander Błaszkiewicz
- Index code repositories for background analysis – Aleksander Błaszkiewicz
- Add a "Pending release" issue status that resolves issues for older releases and reopens them only when they occur in a new release – Aleksander Błaszkiewicz
Objective 4: Keep Error Tracking bills predictable (Owner: Cory Slater)
Motivation: Customers should not receive unexpectedly high bills after exception-volume spikes.
What we'll ship:
- Complete the design for automatic rate limiting – Cory Slater
- Define subscription pricing with the APM team – Cory Slater
Objective 5: Fit enterprise workflows (Owner: Hugues Pouillot)
Motivation: Large customers need stronger integrations, repeatable configuration, and a clearer path from an Error Tracking issue to their existing engineering workflows.
What we'll ship:
- Improve integrations with Linear, Jira, GitHub, and GitLab – Hugues Pouillot
- Add configuration as code – Hugues Pouillot
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