Customizing error reports

In order to quickly reproduce and fix errors, it is often helpful to send additional application-specific diagnostic data to BugSnag.

Before notify callbacks

If you’d like to add diagnostic data to every error report, or adjust error reports conditionally, you can use a before notify callback, which will be run before each error report is sent:

bugsnag.addCallback(new Callback() {
    public void beforeNotify(Report report) {
        report.addToTab("account", "name", "Acme Co.");
        report.addToTab("account", "paying_customer", true);

The Report methods support chaining, for example:


BugSnag will automatically add diagnostic information on the JVM runtime, O/S, and locale. For javax.servlet API apps information about the request will be collected.


Sets a piece of information to be displayed on the error in BugSnag. The first argument is the tab name, the second argument is the key for the data, and the third argument is used as the value. Also see clearTab.

report.addToTab("system resources", "memory", "10MB");

If you are using the logback appender then you can add metadata to every report by adding the following in your logback.xml file:

<appender name="BUGSNAG" class="com.bugsnag.BugsnagAppender">
            <name>system resources</name>

It is possible to add metadata to all reports on the current thread, see Thread metadata.


Prevents the report from being sent to BugSnag.



Clears a tab of information so it will not be sent to BugSnag. Also see addToTab.

report.clearTab("system resources");


Returns the thrown Throwable that is being reported.


Returns the full name of the Throwable that is being reported.


Returns the Throwable‘s array of StackTraceElements.


Deprecated: Use addToTab instead.

Set information about the application the error occurred on, to appear on the app tab.

report.setAppInfo("Module", "parser");


Set the context of the error. Defaults to the class the error occurred in.



Deprecated: Use addToTab instead.

Set information about the device the error occurred on, to appear on the device tab.

report.setDeviceInfo("Cluster number", "2");


Sets the groupingHash used by BugSnag to manually override the default grouping technique. This is an advanced option, and should be used with care.

Any errors that are sent to BugSnag that have the same groupingHash will be grouped as one. As the name implies, this option accepts a hash of sorts.

// ... generate the hash
String groupingHash = "f8803769f3e293dfcabdb6dec5100b8c52c6ae6b";


Set information about the user the error occurred for. Details can also be set individually, see setUserId, setUserEmail and setUserName.

report.setUser("12345", "", "User Name");


Set the email address of the user the error occurred for. Also see setUser.



Set an identifier for the user the error occurred for. Also see setUser.



Set the name of the user the error occurred for. Also see setUser.

report.setUserName("User Name");


Overrides the severity of the error. Valid severities are ERROR, WARNING and INFO.


Thread metadata

If you have data that is relevant to the work a thread is doing (such as the current message being processed) then it is also possible to add MetaData to any logs on the thread:

Bugsnag.addThreadMetaData("message", "id", "12345");
bugsnag.notify(new RuntimeException("Message ID will be included here"), Severity.ERROR);
bugsnag.notify(new RuntimeException("and also here"), Severity.INFO);

If your threads are reused to run multiple tasks, such as in a ThreadPoolExecutor, then you should ensure that MetaData is cleared at the end of each task. Thread metadata will be automatically cleared at the end of an HTTP request.

Bugsnag.clearThreadMetaData(); // clear all MetaData for the current thread

It is also possible to remove a particular tab from the thread metadata, or a particular key.

Bugsnag.clearThreadMetaData("tabToClear"); // clear thread metadata tab
Bugsnag.clearThreadMetaData("tabToClear", "keyToClear" ); // clear thread metadata key