Add BugSnag to your Java projects to automatically capture and report exceptions on production.
New to BugSnag? Create an account
Looking for performance monitoring? See our performance guide
Add bugsnag to the dependencies section in your build.gradle or build.gradle.kts:
implementation 'com.bugsnag:bugsnag:4.+'
implementation("com.bugsnag:bugsnag:4.+")
The latest available version of bugsnag-java is v4.0.0.
Add bugsnag as a dependency in your pom.xml:
<dependency>
<groupId>com.bugsnag</groupId>
<version>[4.0,5.0)</version>
<artifactId>bugsnag</artifactId>
</dependency>
BugSnag Java uses SLF4J for internal logging, which provides a facade to several popular logging libraries. If you do not specify which logging library you wish to use, a no-operation implementation which outputs a build warning will be used.
To suppress this build warning, you should add one of the SLF4J bindings as either a Gradle/Maven dependency in your project, or as a Jar file.
Import the Bugsnag class in your code and create an instance to begin capturing exceptions:
Bugsnag bugsnag = new Bugsnag("your-api-key-here");
You can find your API key in your project’s settings (shortcut: gs) in the dashboard.
If you are using logback you can configure a BugSnag log appender to automatically report logged exceptions. See configuring logback for additional setup instructions.
If you’d like to configure BugSnag further, see the configuration options reference.
After completing installation and basic configuration, unhandled exceptions will be automatically reported to your BugSnag dashboard.
BugSnag attaches a Thread.UncaughtExceptionHandler to detect and report any uncaught exceptions thrown in your application.
If you do not want BugSnag to automatically report unhandled exceptions, you can disable this using the autoDetectErrors configuration option:
Bugsnag bugsnag = new Bugsnag("your-api-key-here", false);
If you would like to send handled exceptions to BugSnag, you can pass any Throwable object to the bugsnag.notify method:
try {
// Some potentially crashy code
} catch (Exception exception) {
bugsnag.notify(exception);
}
This will create and send an event for a “handled” error, with the default severity “warning”.
It can often be helpful to adjust the severity or attach custom diagnostics to handled exceptions. For more information, see Reporting handled exceptions.
If you configure the logback appender exceptions will be sent to BugSnag when you include the Throwable parameter in a Logger call:
private static final Logger logger = Logger.getLogger(MyClass.class);
try {
// Some potentially crashy code
} catch (Throwable exception) {
logger.warn("Something went wrong here", exception);
}
For configuration instructions see configuring logback.
It can often be helpful to attach application-specific diagnostic data to error reports. This can be accomplished by setting a callback which will be invoked before any reports are sent to BugSnag:
bugsnag.addOnError((event) -> {
event.addMetadata("subsystem", "name", "Your subsystem name");
return true;
});
For more information, see Customizing error reports.
In order to correlate errors with customer reports, or to see a list of users who experienced each error, it is helpful to capture and display user information. BugSnag includes helpers for attaching an identifier, email address and name to reports that will be searchable in the dashboard.
By default we will generate a unique ID and send this ID along with every error report from an individual device. If you would like to override this identifier you can set the user ID property.
bugsnag.addOnError((event) -> {
event.setUser("User ID", "user@example.com", "User Name");
return true;
});
For more information, see Customizing error reports.
BugSnag will automatically populate details of requests such as the client IP address and request URL for handled and unhandled exceptions.
Check out the full list of captured data for more details.
To report exceptions thrown by servlets you should implement your own error handler and call bugsnag.notify() from within it.
BugSnag tracks the number of “sessions” that happen within your application. This allows you to compare stability scores between releases and helps you to understand the quality of your releases.
For plain Java applications, a session is captured and reported for each HTTP request which uses the Servlet API. This behavior can be disabled using the autoCaptureSessions configuration option.
If you want full control over what is deemed a session, you can switch off automatic session tracking with the setAutoCaptureSessions option, and call startSession() directly.
Monitor errors as you roll out features or run experiments and A/B tests by declaring your feature flag and experiment usage in the BugSnag SDK. You can use the Features dashboard to identify whether these features have introduced errors into your app.
bugsnag.addFeatureFlag("Checkout button color", "Blue");
bugsnag.addFeatureFlag("New checkout flow");
For more information, see Feature flags.
Configure your app version to see the release that each error was introduced in.
bugsnag.setAppVersion("1.0.0");
Then set up a build tool integration to enable linking to code in your source control provider from the releases dashboard, timeline annotations, and stack traces.
bugsnag-java, the library powering BugSnag for Java, on GitHub