Frequently asked questions

Contents

Why isn’t Bugsnag automatically reporting exceptions?

If manual calls to Bugsnag.notify() are showing up in the Bugsnag dashboard, but uncaught exceptions are not, then there are several possible reasons:

1. Check your configuration

The following configuration options might have been used to disable the autonotify behavior.

2. Errors thrown from the console

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.

3. Cross origin script errors

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.

4. Code generated with 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.

How do I use Bugsnag in third-party embedded JavaScript?

Bugsnag has a noConflict function for removing itself from the window object and restoring the previous binding. This is intended for use in environments where developers can’t assume that Bugsnag isn’t in use already (such as 3rd party embedded javascript) and want to control what gets reported to their Bugsnag account.

The object returned from noConflict() is the full Bugsnag object so can be used in the same way:

var myBugsnag = Bugsnag.noConflict();
// window.Bugsnag is now bound to what it was before the Bugsnag script was
// loaded.
myBugsnag.apiKey = "my-special-api-key";
try {
  // highly volatile code
} catch (e) {
  myBugsnag.notifyException(e, "OhNoes");
}

How do I load Bugsnag with AMD or CommonJS?

Bugsnag can be loaded as-is using an AMD or CommonJS compatible loader. This means you can use it with tools like RequireJS and Browserify directly. If you want to load Bugsnag from the CDN but load the rest of your code using AMD, then you should ensure Bugsnag is required before the rest of your code.

If you load Bugsnag after the rest of your code, and your AMD loader leaks the global define function then you may see the (harmless) error message: Mismatched anonymous define() module. To fix this, load Bugsnag before the rest of your code.

How can I disable sending inline script content to Bugsnag?

By default Bugsnag sends the contents of inline script tags on the page to our servers to help with analysis and debugging. If you don’t want this to happen, set inlinescript to false.

<script src="//d2wy8f7a9ursnm.cloudfront.net/bugsnag-3.min.js"
        data-inlinescript="false"></script>

How do I notify Bugsnag about jQuery Ajax errors?

$(document).ajaxError(function(event, jqxhr, settings, thrownError) {
  Bugsnag.notify("AjaxError", thrownError);
});

How do I show un-minified source code on my Bugsnag dashboard?

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=//d2wy8f7a9ursnm.cloudfront.net/bugsnag-2.1.0.min.map

Most modern minifiers 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. Legitimate Bugsnag requests originate from the IP address 107.22.198.224 if you need to open up your firewall to allow access.

How can I adjust the number of errors sent per page load?

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. If you have a long-running single page app, you can reset this rate limit from your router by using:

Bugsnag.refresh()

How can I lock to a specific version of the Bugsnag library via the CDN?

We will occasionally update the major 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="//d2wy8f7a9ursnm.cloudfront.net/bugsnag-2.5.0.min.js"
        data-apikey="YOUR-API-KEY-HERE"></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 your onload handlers run. This is so that we can report stacktraces reliably.

How can I get error reports from browser extensions?

Bugsnag’s backend automatically ignores 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 extension, you might add something like this to your beforeNotify function:

Bugsnag.beforeNotify = function (error, metaData) {
    error.stacktrace = error.stacktrace.replace(/chrome-extension:/g, "chrome_extension:");
}

Can I use Bugsnag with CSP?

Yes, you can use Bugsnag with CSP even if you do not use unsafe-eval or unsafe-inline directives. If you are following our standard setup instructions, you’ll need to add these two items to your existing script source and image source CSP headers:

script-src https://d2wy8f7a9ursnm.cloudfront.net
image-src https://notify.bugsnag.com

If you’d prefer, you can also host bugsnag-js on your own site or CDN to avoid adding the bugsnag-js script-src. Just be sure to load it before your other javascript so it can report errors in as much of you code as possible.

Can I load Bugsnag async?

We recommend loading Bugsnag synchronously before any of your other scripts to maximize compatibility with older browsers and report as many of your errors as possible. Bugsnag shims some functions in older browsers to provide better stacktraces, but this functionality only works if bugsnag-js executes before your javascript.

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.

Remember that you’ll need to set your API key and other configuration options in javascript if you don’t load Bugsnag via its own script tag.

Is Bugsnag blocked by ad blockers?

Some ad blockers will prevent the Bugsnag notifier from loading and therefore it will not report errors.

In most cases Bugsnag will only be blocked if it is included as a script with the name bugsnag-x.min.js. See the self-hosting options for options to work around this.

The following ad blockers are known to block Bugsnag by default:

  • uBlock Origin & uBlock: Bugsnag will be blocked unless the EasyPrivacy list is disabled.
  • 1Blocker: Bugsnag will be blocked unless the Bugsnag rule is disabled.

The following ad blockers may block Bugsnag if the default configuration is changed:

Why is my payload not being sent/being rejected with status code 413?

In order to achieve the widest possible browser support, the bugsnag-js notifier sends payloads in the querystring of a GET request.

Unfortunately, both browsers and servers place arbitrary upper limits on the amount of data that can be sent as part of a URL. For example, GCP (where we host Bugsnag) document an enforced limit of 2k-8k characters. This detailed Stack Overflow answer recommends that the safest upper limit to use is 2k.

The practical implications of this are that sending large data structures in the metadata arguments may result in either a browser refusing to send a payload, or a proxy/server refusing to receive it. In the latter example, the HTTP status code received will be 413.