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 can prevent automatic reporting of some or all errors:

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 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=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:

  • 104.196.245.109
  • 104.196.254.247

How can I reject errors that don’t originate from my domain?

In some cases, errors can be reported from domains/URLs that are not part of your app. If these errors are 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.

You can read more about allowed domains on the managing event usage product page.

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. 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:

Bugsnag.refresh()

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

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.

How can I get error reports from browser extensions?

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 onError function:

Bugsnag.start({
  onError: function (event) {
    event.errors[0].stacktrace = event.errors[0].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
    })
  }
})

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.

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

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.

Can I load BugSnag async?

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.

How can I tell if BugSnag has finished initializing?

Calling BugSnag static client methods, such as Bugsnag.leaveBreadcrumb() and Bugsnag.addMetadata(), will throw an exception if you have not yet called Bugsnag.start().

You can use Bugsnag.isStarted() to check whether the BugSnag client has been initialized.

Is BugSnag blocked by ad blockers?

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:

  • 1Blocker: BugSnag will be blocked unless the BugSnag rule is disabled.
  • Privacy Badger: BugSnag will be blocked unless explicitly allowed.
  • uBlock Origin: BugSnag will be blocked unless explicitly allowed.

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

Does BugSnag use cookies?

The BugSnag error reporting library does not create or use cookies. An anonymous ID is persisted in local storage so that the user stability score can be calculated unless disabled by configuring generateAnonymousId.