Best practices for JavaScript error monitoring

Once you start javascript error monitoring, you might notice that the errors are pouring down like a waterfall. You might encounter numerous errors, some of which you are not responsible or cannot fix them. You need to avoid the noise and get into the real issues that are affecting your users. Here is how you do it…

Atatus monitors your production JavaScript web application. You shall know when your users run into errors and fix them. You can start monitoring errors in your JavaScript applications with a few best practices in mind:

1. Domain whitelisting

Domain whitelisting is a powerful way to eliminate many of the noisy JavaScript errors you don’t care about. Atatus allows you to whitelist your domain so you can automatically ignore errors that happen on other domains, even if they’re using your API key. This way you can focus solely on the errors you know are coming from your JavaScript code.

As an example, if you load some debugging scripts or third-party scripts from another domain, whitelisting lets you automatically ignore errors from those scripts. It also saves you trouble in the case where someone copy-pastes all your JavaScript onto another website or a local file and starts doing weird stuff with it that throws errors, which is actually oddly common for large sites. With Atatus, you can whitelist your domains as follows

atatus.setAllowedDomains(['', '', '']);

2. Dealing with Script Error

If your page loads scripts from different domains, you might see a lot of Script Error messages. These unhelpful messages occur because the browser’s same-origin security policy is preventing the error information from one domain (hosting scripts) from leaking to another (your page).In order to get visibility into errors thrown from scripts originating from different origins, you must set two things.

  1. Cross origin attribute
  2. CORS HTTP header

Cross origin attribute

When including the external JavaScript file in script tag, add the crossorigin attribute to the tag.

<script src="" crossorigin="anonymous"></script>

CORS HTTP header

Each server, CDN, or vendor that you load JavaScript assets from needs to serve the request with the CORS headers:

Access-Control-Allow-Origin: *

3. Use Sourcemaps

One of the most powerful tools you can use to debug in JavaScript, and any language for that matter, is to see the line of code that crashed. If you minify your JavaScript code, you’ll need to setup sourcemaps to make this work, but it’ll be worth your time in terms of the effort and hassle you’ll avoid down the line. Sourcemaps will map your minified code to your actual lines of code, so that Atatus can show you your code in the stacktrace.

If your source map is publicly web-accessible, we shall download it automatically. Otherwise, you can upload it via our API. You can know more about source maps here

4. Set User Identifier

Atatus allows several places for you to specify additional information about your application and who’s using it. This information can provide valuable context when fixing errors.

Because JavaScript monitoring can be noisy, looking at raw error counts alone can make it difficult to understand what’s happening. A serious spike in errors could be caused by only one user, in which case it isn’t as serious as you thought. But you could waste a lot of time investigating along the way, only to discover it isn’t something worth spending your time fixing. If you correlate errors to users or IP address, you’ll be able to map errors to the number of users affected.

You can sort errors by event and user counts in Atatus which is really helpful for understanding the overall impact of an error. With Atatus, you can set a user:


5. Set version to your JS to trace each error

People can keep a single browser window open for days without refreshing it, and so there’s no guarantee that your current deployment includes the code that caused the error. In Atatus, we allow you to easily track JavaScript deployments. Assigning your JavaScript a unique version number lets you know whether you truly fixed a bug with the latest deploy (and you’re just seeing a final few errors trickling in from older versions of your JS), or if you’re still seeing the same bug hanging around in your new code.

You can set a version for your app as follows:


6. Disable console display

By default Atatus will watch all console activity and include that information in the Timeline. Also any calls to console.error() will automatically trigger an error. If you’re worried that your users might see things, you can turn off console visibility in production with the following configuration:

atatus.config('YOUR_API_KEY', {

   // Set this to false if you don't want your users seeing
   // anything when the dev tools open.
   consoleDisplay: false


You’ll still get great context from your console logs, but your users won’t be concerned by it!

Get started with Atatus free 14 day trial – no credit card required. If you have any questions, we’d love to hear from you.


#1 Solution for Logs, Traces & Metrics

tick-logo APM

tick-logo Kubernetes

tick-logo Logs

tick-logo Synthetics

tick-logo RUM

tick-logo Serverless

tick-logo Security

tick-logo More



CMO at Atatus.