Every captured exception is assigned a fingerprint. This fingerprint is used to group similar exceptions into issues. This page covers how fingerprints are generated, how they're used, and how you can override them when capturing exceptions.
Fingerprint and issue grouping
Every exception has a fingerprint, whether generated or defined by the user. Each fingerprint links to exactly one issue. Exceptions that share the same fingerprint define an issue.
Multiple different fingerprints can point to the same issue (a many-to-one relationship) if you merge issues.
How are fingerprints generated?
Fingerprints are built iteratively using components of the exception event. The flowchart below shows how fingerprints are generated.
The flowchart in text
Fingerprints are generated by considering the following in combination:
- The exception type
- If there's no resolved stack trace, add the error message to the fingerprint
- If there are stack traces but no in-app frames (frames from your code, not a dependency), use the first frame of the stack trace
- If there are stack traces, in-app frames, and source maps available, use the resolved in-app stack frames
- If there are stack traces, in-app frames, and source maps not available, use the first in-app stack frame
In some languages, like Python, one error can trigger another, creating a chain of linked exceptions. PostHog records the entire chain in the event and generates a single fingerprint for it.
Ensuring accurate fingerprints
Resolved stack traces are critical for accurate fingerprinting. Without accurate stack traces, PostHog cannot group exceptions consistently. If you have not uploaded source maps, follow the source map guide to do so.
This also means that if the exception type or message changes from one version to the next, the fingerprint will change.
When are generated fingerprints used?
Fingerprints are used to group similar exceptions into issues automatically. Automatic issue grouping is only done when:
- No issue grouping rules are applied
- No issue merging has been configured
- No custom fingerprint is set during capture
You can find details about how issue grouping works in the issues and exceptions guide.
Customizing fingerprints
Fingerprints can be manually set during exception capture. This is a very useful way to group exceptions that are not related to each other. You can find examples of how to do this in the custom issue grouping section.
You can also learn more about grouping issues using rules in the grouping issues guide.