What error tracking captures versus what it should alert on
Once installed, PostHog's error tracking captures unhandled exceptions (and, depending on SDK and configuration, some handled ones you explicitly report) with stack traces, breadcrumbs, and the same person/session context as your other events - which is the real advantage over a standalone error tool: an error shows up next to the session replay and event history for the same user, not in a separate dashboard you have to cross-reference by hand.
Capturing every error and alerting on every error are different decisions. Most installs get the first right and skip the second, which is why error channels get muted.
Implementation done properly
| Layer | What to configure deliberately |
|---|---|
| Capture scope | Which error types and severity levels actually get sent - not every caught exception needs to leave the client |
| Grouping / fingerprinting | Similar errors need to collapse into one issue, or volume becomes unreadable noise instead of a prioritized list |
| Alert rules | Threshold-based (new issue, spike in known issue, error rate crossing a level) rather than one alert per occurrence |
| Routing | Alerts reach the team that owns the affected code path, not one shared channel everyone eventually mutes |
| Live debugger breakpoints | For errors that need runtime inspection beyond a stack trace - a narrower, more advanced capability worth scoping only where stack traces alone are not enough |
Monitoring dashboards that survive contact with a real incident
A monitoring view built for error tracking should answer three questions fast: is this a new issue or a known one, is the rate climbing or steady, and which release introduced it. A dashboard that just lists raw error counts without those framings gets checked once and then ignored.
How to verify it worked
- Trigger a real error in a staging environment and confirm it appears in PostHog with the expected grouping - not as a duplicate issue for something already tracked.
- Confirm the alert rule actually fires on the condition you configured, not on every occurrence - test both a single occurrence (should not alert, if you configured a threshold) and a burst (should alert).
- Check that the alert lands with the recipient who owns that code path, and that they can trace it back to the originating release or deploy.
- Revisit the alert channel after a week - if it has already been muted or ignored, the threshold or routing is wrong, not the team.