# Fingerprints - Docs

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](/docs/error-tracking/managing-issues.md#merging-issues).

## 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 trace<br/>available?} B -->|No| C\[Add error message to fingerprint\] C --> D\[Final fingerprint\] B -->|Yes| E{In-app frames<br/>exist?} E -->|No| F\[Add first frame to fingerprint\] E -->|Yes| G\[Add in-app frame to fingerprint<br/>Priority: 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](/docs/error-tracking/stack-traces.md) 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](/docs/error-tracking/upload-source-maps.md) 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](/docs/error-tracking/grouping-issues.md) are applied
-   No [issue merging](/docs/error-tracking/managing-issues.md#merging-issues) has been configured
-   No [custom fingerprint](#customizing-fingerprints) is set during capture

You can find details about how issue grouping works in the [issues and exceptions](/docs/error-tracking/issues-and-exceptions.md) 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](/docs/error-tracking/grouping-issues.md#option-2-client-side-fingerprint) section.

You can also learn more about grouping issues using rules in the [grouping issues](/docs/error-tracking/grouping-issues.md) guide.

### Community questions

Ask a question

### Was this page useful?

HelpfulCould be better