Error grouping and the occurrence counter

A single problem in an application can generate hundreds or even thousands of identical exceptions. When every occurrence is shown separately, it's hard to tell a single incident apart from a problem affecting a large share of your traffic.

That's why reports are grouped by their fingerprint. Repeated occurrences of the same problem end up in a single report, and a counter shows its scale.

What determines the grouping?

The fingerprint is built from information that identifies a specific type of problem, including the project, the exception type and the error message.

This matters because an identical message occurring in two different applications still represents two independent problems.

Why does grouping matter?

Imagine an error that occurred 3,500 times within an hour. You don't need 3,500 identical entries in the list. You need to know what problem occurred, when it appeared and how often it happens.

Grouping is exactly what makes this possible. A single entry represents the problem, and the counter shows its scale.

Occurrence history

The report details let you analyse the history of a problem and see how the number of its occurrences has changed over time.

This makes it easier to connect a rise in the number of errors with a deployment, a configuration change or a specific event in the application.

Recurring errors and notifications

A recurring error shouldn't trigger a separate email for every occurrence. Notifications are meant to draw attention to new or significant problems, not flood your inbox with copies of the same event.

This matters especially during an outage, when a single problem can generate a very large number of exceptions in a short time.