This documentation is for version 6 of the BugSnag JavaScript notifier. We recommend upgrading to the latest release using our Upgrade guide. Documentation for the current release can be found here.
If manual calls to bugsnag.notify() are showing up in the BugSnag dashboard, but uncaught exceptions are not, then there
are several possible reasons:
The following configuration options might have been used to disable the autonotify behavior.
An error that is explicitly thrown in the browser console, e.g. throw new Error('test'), will not
automatically be tracked. This is because it does not trigger the window.onerror handler that
BugSnag uses to track uncaught exceptions.
BugSnag ignores cross domain script errors by default, because they contain no useful information.
When BugSnag encounters these errors it will log to the browser console:
[Bugsnag] Ignoring cross-domain script error.
See the documentation on capturing cross-domain script errors for the solution and more information.
eval (e.g from webpack)Many tools such as webpack will generate code with eval as a cheap alternative
to source maps. Like cross origin script errors, these errors from evaled code hide all useful information
and will thus be ignored.
If you are using webpack, you should change the devtool
option in your webpack config to something that does not use eval.
We recommend source-map or inline-source-map.
BugSnag supports source maps to reverse javascript minification. If you include a magic comment at the end of your javascript file that points to the location of a source map, we will expand the lines in your stacktrace.
For example, the source map comment at the bottom of bugsnag.js looks similar
to this:
//# sourceMappingURL=bugsnag.min.js.map
Most modern minifiers and bundlers support source maps. We use UglifyJS2.
To support source maps BugSnag needs to download both your minified code and your source maps. It doesn’t need to fetch your original source files. If you need to open up your firewall to allow access, legitimate BugSnag requests originate from the IP addresses:
In some cases, errors can be reported from domains/URLs that are not part of your app. If these errors not not useful to you, you can set up allowed domains so that only errors matching an allowed domain will be processed by BugSnag.
You can set up allowed domains in your BugSnag dashboard: Project Settings -> Allowed domains.
By default only 10 errors are allowed per page load. This is to prevent wasting a user’s bandwidth sending thousands of exceptions to BugSnag. This count is automatically reset each time the page location changes via pushstate/replacestate, however if you have a long-running single page app that does not change URL, you can reset manually by using:
bugsnagClient.refresh()
We will occasionally update the minor/patch version of BugSnag on the CDN to improve the quality of our notifier without breaking backward compatibility. If you need assurance that the JavaScript will never change, feel free to include the specific version directly.
<script src="https://d2wy8f7a9ursnm.cloudfront.net/v4.0.0/bugsnag.min.js"></script>
If you have specific requirements for Javascript, you’re welcome to host versions of bugsnag-js on your own site or CDN.
If you’d like to avoid an extra blocking request, you can include the javascript in your asset compilation process so that it is inlined into your existing script files. The only thing to be sure of is that BugSnag is included before the rest of your JavaScript runs – BugSnag can only catch errors in code that executes after it.
BugSnag’s backend automatically discards errors if they appear to come from browser extensions, since these errors usually aren’t actionable for site owners and often aren’t related the current page’s code at all.
If you have a special case where you want to know about errors that come from
extensions — for example, if you are attempting to monitor a browser extension
itself — you may need to modify the error stacktrace you send to BugSnag to work
around this feature. For example, for a Chrome or Firefox extension, you might add
something like this to your beforeSend function:
bugsnag({
beforeSend: function (report) {
report.stacktrace = report.stacktrace.map(function (frame) {
frame.file = frame.file.replace(/chrome-extension:/g, 'chrome_extension:')
frame.file = frame.file.replace(/moz-extension:/g, 'moz_extension:')
frame.file = frame.file.replace(/safari-extension:/g, 'safari_extension:')
frame.file = frame.file.replace(/safari-web-extension:/g, 'safari_web_extension:')
return frame
})
}
})
Yes, you can use BugSnag with
CSP, even if you do
not use unsafe-eval or unsafe-inline directives.
Our error reporting and session APIs are located at subdomains of bugsnag.com, so
you’ll need to add a connect-src directive for them:
connect-src *.bugsnag.com
Note: for On-premise users, this host should be updated accordingly.
Additionally, if you are loading bugsnag-js from the CDN, you’ll need to add the
CDN host to your script-src directive:
script-src d2wy8f7a9ursnm.cloudfront.net
If you’re hosting bugsnag-js yourself and serving it along with your other JavaScript,
you should already have a working rule in place for script-src – just add the connect-src
directive above.
We recommend loading BugSnag synchronously before any of your other scripts to report as many of your errors as possible.
If async loading of all of your javascript is important to you, we recommend bundling bugsnag-js with your own scripts and including it as the first file in your asset compilation process so that it can still run before your other scripts.
It is available on npm as @bugsnag/js.
Some ad blockers will prevent the BugSnag notifier from loading or block errors and sessions from being sent.
The following ad blockers are known to block BugSnag by default:
The following ad blockers may block BugSnag if the default configuration is changed:
The BugSnag error reporting library does not create or use cookies.