Customizing error grouping

Honeybadger uses the error’s class name to group similar errors together. This works well for most cases, but you may want to customize grouping when:

• Your error classes are generic (such as errors.errorString)
• You want to group related errors together regardless of their class
• You want to separate errors that have the same class but different causes

Overriding the error class

If your error classes are often generic, you can improve grouping by overriding the default class name with something more specific using ErrorClass:

honeybadger.Notify(err, honeybadger.ErrorClass{"DatabaseConnectionError"})

All errors with the same error class will be grouped together.

Using custom fingerprints

To override grouping entirely, you can send a custom Fingerprint. All errors with the same fingerprint will be grouped together, regardless of error class:

honeybadger.Notify(err, honeybadger.Fingerprint{"checkout-payment-failed"})

Fingerprints are useful when you want complete control over how errors are grouped. For example, you might want to group all payment-related errors together regardless of the underlying error type.

Combining with other options

You can combine error class or fingerprint with other notification options:

honeybadger.Notify(err,
    honeybadger.ErrorClass{"PaymentError"},
    honeybadger.Context{"order_id": 12345},
    honeybadger.Tags{"payment", "checkout"},
)

Advanced: Using BeforeNotify for dynamic grouping

For more complex grouping logic, you can use BeforeNotify to dynamically set the fingerprint based on the error. One common use case is grouping errors.errorString errors by their message instead of class:

honeybadger.BeforeNotify(
    func(notice *honeybadger.Notice) error {
        if notice.ErrorClass == "errors.errorString" {
            notice.Fingerprint = notice.Message
        }
        return nil
    }
)

Note that in this example, the backtrace is ignored. If you want to group by message and backtrace, you could append data from notice.Backtrace to the fingerprint string.

An alternate approach would be to override notice.ErrorClass with a more specific class name that may be inferred from the message.