Error tracking

Error tracking collects the exceptions that a running application throws, groups duplicates of the same fault into a single issue, and records the context needed to diagnose each one. Error Tracking is also the name of the PostHog product that does this.^[2]

What problem it solves[edit]

An application in production fails in ways its developers did not anticipate, on devices and in states they do not have. The failures reach a log file, where a single fault appears thousands of times and a rare fault is buried under a common one.

Error tracking solves three specific parts of this:

• Volume. Thousands of occurrences of one fault become one issue with a count.
• Priority. An issue that affects many people, or has just started, can be separated from one that has been rare for a year.
• Context. A stack trace alone rarely explains a fault. What the person was doing beforehand usually does.

How it works in PostHog[edit]

An exception is captured as an event, in the same stream as everything else.^[1] PostHog then groups the occurrences into an issue, and each issue carries:

• The stack trace, resolved back to the original source where source maps have been uploaded.
• The count over time, so a new or growing issue is visible.
• The people affected, and their properties.
• The session replay of the session that threw it.
• The events that preceded it in that session.

The last two are the part that is specific to PostHog. Because errors and recordings are the same data, an engineer can watch the person hit the fault, rather than reconstruct the sequence from a trace.

Issues can be assigned, resolved, and suppressed, and an alert can be raised when an issue is created, reopened, or starts to spike.^[1]

How it relates to other PostHog products[edit]

See also

References

1. ^PostHog documentation, Error tracking
2. ^PostHog Error Tracking

External links

• PostHog Error Tracking
• Error tracking documentation