Fingerprints

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 (opens in a new tab).

How are fingerprints generated?

Fingerprints are built iteratively using components of the exception event. The flowchart below shows how fingerprints are generated.

flowchart LR A[Add exception type to fingerprint] --> B{Stack traceavailable?} B -->|No| C[Add error message to fingerprint] C --> D[Final fingerprint] B -->|Yes| E{In-app framesexist?} E -->|No| F[Add first frame to fingerprint] E -->|Yes| G[Add in-app frame to fingerprintPriority: resolved > unresolved] F --> D G --> D

The flowchart in text

Fingerprints are generated by considering the following in combination:

1. The exception type
2. If there’s no resolved stack trace, add the error message to the fingerprint
3. 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
4. If there are stack traces, in-app frames, and source maps available, use the resolved in-app stack frames
5. 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 (opens in a new tab) 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 (opens in a new tab) 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 (opens in a new tab) are applied
• No issue merging (opens in a new tab) has been configured
• No custom fingerprint is set during capture

You can find details about how issue grouping works in the issues and exceptions (opens in a new tab) 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 (opens in a new tab) section.

When you set a custom fingerprint, you can also name the resulting issue with the $issue_name and $issue_description properties:

JavaScript

PostHog uses these two properties only on the event that creates the issue, and truncates each to 255 characters. Later events on the same fingerprint keep the existing name and description. When you do not set them, PostHog uses the exception type as the name and the exception message as the description.

You can also learn more about grouping issues using rules in the grouping issues (opens in a new tab) guide.

Still have questions?

Ask PostHog AI

Was this page useful?

HelpfulCould be better