Bugsnag

BugSnag is now Insight Hub – we're making some changes to how the product looks, but this won't impact the way you use BugSnag or any of your integrations. Platform guides Step-by-step instructions for installing and configuring BugSnag in your applications. BugSnag provides error reporting libraries for over 50 different platforms, listed in the navigation to the left. These integration guides help you quickly add BugSnag to your applications. Add BugSnag to your Android apps Add BugSnag to your C/C++ projects Add BugSnag to your Cocos2d-x games Add BugSnag to your Electron projects Add BugSnag to your Flutter apps Includes support for Gin, Negroni, net/http, Revel, and other Go apps Add BugSnag to your iOS & iPadOS projects Includes support for Spring and other Java apps Add BugSnag to your JavaScript applications in the browser and Node.js. Add BugSnag to your macOS projects Includes support for ASP.NET Core, ASP.NET, ASP.NET MVC, ASP.NET Web API, WPF, and other .NET apps Add BugSnag to your Nintendo Switch games Includes support for Laravel, Lumen, Symfony, Wordpress and other PHP apps Includes support for ASGI, AWS Lambda, Bottle, Celery, Django, Flask, Tornado, WSGI, and other Python apps Add BugSnag to your React native and Expo apps Includes support for Rack, Rails, Rake, Sidekiq, Sinatra, and other Ruby apps Add BugSnag to your tvOS projects Add BugSnag to your Unity games Add BugSnag to your Unreal Engine games Add BugSnag to your Apple Watch projects If your platform is not officially supportedSearchcommunity supported librariesSend us a support requestDevelop a custom BugSnag integration using our error reporting API and writing a notifier guide

BugSnag is now Insight Hub – we're making some changes to how the product looks, but this won't impact the way you use BugSnag or any of your integrations. Sinatra integration guide Add BugSnag to your Sinatra and Padrino projects. InstallationAdd the bugsnag gem to your Gemfile: The latest available version of bugsnag is v6.27.1.Basic configurationTo identify your app in the BugSnag dashboard, you’ll need to configure your BugSnag API key. You can find your API key when creating a project in your BugSnag dashboard, or later from your project settings page.To set your API key in your Sinatra app, add the following code to your config.ru file:require 'bugsnag'Bugsnag.configure do |config| config.api_key = 'YOUR_API_KEY_HERE'endAlternatively, you can set the BUGSNAG_API_KEY environment variable.You can find your API key in Project Settings from your BugSnag dashboard.If you’d like to configure BugSnag further, check out the configuration options reference.Reporting unhandled exceptionsTo automatically capture unhandled exceptions, you’ll need to enable the BugSnag Rack middleware:use Bugsnag::Rackset :raise_errors, trueset :show_exceptions, falseAt this point, BugSnag should be installed and configured, and any unhandled exceptions will be automatically detected and should appear in your BugSnag dashboard.Note: If you wish to use custom error handlers in your app, then you need to notify BugSnag explicitly.error 500 do Bugsnag.notify($!) erb :'errors/500'endReporting handled exceptionsReporting handled exceptions can be accomplished as follows:begin raise 'Something went wrong!'rescue => exception Bugsnag.notify(exception)endAdding diagnostics or adjusting severityIt can often be helpful to adjust the severity or attach custom diagnostics to handled exceptions. For more information, see reporting handled errors.Avoiding re-notifying exceptionsSometimes after catching and notifying a handled exception you may want to re-raise the exception to be dealt with by your standard error handlers without sending an automatic exception to BugSnag.This can be accomplished by calling Bugsnag.notify(), adding a custom skip_bugsnag property to your exception, and then

BugSnag is now Insight Hub – we're making some changes to how the product looks, but this won't impact the way you use BugSnag or any of your integrations. Control access to BugSnag using Google Cloud Identity SAML. SetupTo configure BugSnag with Google Cloud Identity SAML:In BugSnag settings select Organization -> Single sign-on (Admin access is required):Copy the SAML endpoint URL to your clipboard.In the Google Admin console, select Apps then SAML Apps and click on the + to Enable SSO for a SAML application.Scroll down and find Bugsnag in the application list and click on it.Under Option 2 download your IDP metadata file. This file will be used as part of the SSO configuration in BugSnag.BugSnag application information is entered by default. Click next.In Service Provider Details:ACS URL – Paste the URL copied from BugSnag.Entity ID – Enter Next.In Attribute Mapping:Add a mapping for User.FirstName and User.LastName as shown in the screenshot.Select Finish.Enable the app for your users as required.In BugSnag:Copy the contents of the previously downloaded IDP metadata file and paste it into the XML Metadata in the SAML/IdP Metadata field.Select Auto-provision collaborators if you would like accounts to be automatically created for new users.Select whether users will be granted access to all current projects or no projects by default. Users will only be added up to your plan’s collaborator limit. After provisioning, access to projects can be managed by any Admin.Select Enable SSO.You can now log in to BugSnag from your Google Cloud Identity SAML apps.Session TimeoutIf

BugSnag is now Insight Hub – we're making some changes to how the product looks, but this won't impact the way you use BugSnag or any of your integrations. Reporting handled errors In order to quickly understand and fix some errors, it is often helpful to sendadditional diagnostic data which is specific to that error.The bugsnag.Notify() function expects one instance of either an error or an errors.Error. Using an errors.Error object captures the stack trace at the call site instead of when Notify() is called, and supports skipping stack frames.// send an error object directlybugsnag.Notify(err)// construct an Error with a format stringbugsnag.Notify(errors.Errorf("broken pipe: %d", code))// wrap an error object, trimming 0 stack frames (more info below)bugsnag.Notify(errors.New(err, 0))Using a logging wrapperIf you have your own logging wrapper all of your errors will appear to originate from inside it, resulting in unrelated events grouping together on the BugSnag dashboard. You can avoid this problem by constructing an Error object using errors.New() and trimming the logging function from the stack trace:import ( "github.com/bugsnag/bugsnag-go/v2" "github.com/bugsnag/bugsnag-go/v2/errors")func LogError(e error) { // 1 removes one line from the stack trace, so the caller of LogError // will be at the top. bugsnag.Notify(errors.New(e, 1))}Appending diagnostic dataIn addition to the error object, Notify accepts several options for customization.Modifier functionThe bugsnag.Notify() function accepts a function as an argument to allow complex customization of the Event created from an error.See the bugsnag.Event object for a list of modifiable properties.bugsnag.Notify(err, func(event *Event) { event.Context = "mail router" // Remove a custom logging function if event.Stacktrace[0].File = "mylogger.go" { event.Stacktrace = event.Stacktrace[1:] } // Count the event in stability score event.Unhandled = true})context.ContextTo track information per session (e.g. per HTTP request) the Go team advocates the context idiom.For most of the frameworks we support including bugsnag.Handler and bugsnag.HandlerFunc BugSnag will automatically attach a context.Context to the request, which can be retrieved through r.Context().If you’re outside the context of a HTTP request, e.g. inside a goroutine, you can call ctx = bugsnag.StartSession(ctx) to let BugSnag track your session.go func() { ctx := bugsnag.StartSession(context.Background()) defer bugsnag.AutoNotify(ctx) // goroutine logic... if err != nil { bugsnag.Notify(err, ctx) }}()If you wish to share the session between two goroutines you should pass the context to your goroutine function:go func(ctx context) { defer bugsnag.AutoNotify(ctx) // goroutine logic... if err != nil { bugsnag.Notify(err, ctx) }}(ctx)bugsnag.ContextNote: This has no relation to the context.Context mentioned above.The context shows up prominently in

BugSnag is now Insight Hub – we're making some changes to how the product looks, but this won't impact the way you use BugSnag or any of your integrations. Learn about how and why events are grouped into errors. BugSnag aims to group instances of the same event together to give you a clear view of which issues are having the biggest impact on your users whilst minimizing unnecessary noise.Individual events are grouped into errors in your inbox and the reason for the grouping is shown at the top of the error view:The error may have been subject to either default or custom grouping. In most cases the default grouping should provide a distinct set of errors, but if you would like to tailor the grouping behavior to your project, a range of custom options are available and are described below.Default groupingUnless custom grouping rules are in place, BugSnag will choose an algorithm to use to group your events based on the language, error reporting SDK and data available in the event. These are as follows:Top in-project stack frame Grouped with other events sharing the same error class, file and line number of the top in-project stack frame of the innermost exception.On most platforms the BugSnag notifier will automatically detect in-project stack frames, but sometimes additional configuration is required to set the root directory of your project. See the docs for your platform.Top in-project stack frame code Grouped with other events where the top in-project stack frame of the innermost exception originates from the same section of code and has the same error class.This algorithm is available for Node.js, PHP, Python, and Ruby projects where sendCode is enabled, and for JavaScript errors in React Native projects.On most platforms the BugSnag notifier will automatically detect in-project stack frames, but sometimes additional

BugSnag is now Insight Hub – we're making some changes to how the product looks, but this won't impact the way you use BugSnag or any of your integrations. In order to quickly understand and fix errors, it is often helpful to send exceptions that have been handled by your application to BugSnag, with additional diagnostic data that is specific to the error. This documentation is for version 7+ of the BugSnag JavaScript notifier. If you are using older versions, we recommend upgrading to the latest release using our Upgrade guide. Documentation for the previous release can be found on our legacy pages.Basic usageIf you would like to send handled errors to BugSnag, you can pass an error to the Bugsnag.notify method.try { // Some potentially crashy code} catch (e) { Bugsnag.notify(e);}This will create and send a report for a “handled” error, with the default severity “warning”.We recommend passing a JavaScript Error object to notify as this is ensures that an accurate stacktrace can be obtained.If you provide something that is not an Error, such as a string or an object with name and message fields, notify will attempt to generate a stacktrace. This works for most cases, but is not as reliable as when an error is provided. If notify is unable to derive an errorClass and message from the argument passed in (for example null, a Function, or an object without suitable properties), the error will be reported to your dashboard but the message will indicate a notifier