JavaScript - - By M. David Green

How to Set Up Airbrake Error Monitoring for Your JavaScript App

This article was sponsored by Airbrake. Thank you for supporting the partners who make SitePoint possible.

We’re all very careful about testing our code before putting it out into a production environment, right? We use test-driven development or build out elegant suites of unit tests, functional tests, and integration tests. We run our products through all the likely environments where it may be deployed repeatedly every time we make a change to our code. We test every possible path a user could follow on every conceivable browser.


Well, ok, none of us is perfect. But at least our users are always diligent about reporting every error they encounter, and providing detailed information about exactly how to reproduce those errors so they’re easy to track down and fix.


Yeah, I didn’t think so.

Error Monitoring to the Rescue!

Thankfully there are services out there to help us diagnose and resolve issues that may have slipped through the infinitesimal cracks in our diligent quality testing procedures.

I’m talking about remote error monitoring services. If you haven’t heard of them before, remote error monitoring services can track and report on actual errors that users encounter in real time as they happen, before the user even has a chance to file a vague or misleading bug report.

In addition, they can provide you with a range of useful details about how the error came about: what browser version the user was running, what account was logged in, what operating system was being used, any session data, a backtrace of the error itself, as well as any custom tags you might have inserted into your code to help identify issues.

Getting Started With Error Monitoring

There are a number of services and options in the market, but a good comprehensive one is They’ve been around for a long time in internet years, so you may remember them as Hoptoad back before they changed their name in 2011.

Airbrake also supports a very broad range of back-end and front end languages and environments from Ruby and PHP to .NET and Node.js. They also offer native integration with most of the popular code management and deployment services such as GitHib, JIRA, Bitbucket, and Slack. It’s likely that whatever you’re working with, they have the tools you need to get started quickly and easily. Their reporting interface is also clean and easy to navigate, so you can start generating actionable information from your deployed production code quickly.

Implementing the code into your product is straightforward. To get started, you can create an account at that’s free for the first 14 days while you kick the tires, with no credit card required during the trial period.

When you create your first project, you’ll be provided with a range of options with pre-written integration code in over 20 languages. As an example, let’s say we want to use JavaScript end-to-end, and have an Express based Node.js api service on the back end.

Monitoring an Express App

Let’s set up a quick example to show how easy integrating error monitoring with Airbrake can be. Assuming we already have node installed, in the terminal we can create a simple Express app to monitor using the Express Generator, which we can install with yarn or npm:

yarn global add express-generator

We can then run it to create a bare-bones Express app:

express sample-app

Then cd into the directory that was created and run yarn (or npm install if you prefer) to install our dependencies

cd sample-app

Then run node bin/www to start our server, optionally setting a port with PORT=#### at the beginning of the command. (If we don’t specify a port, node will default to port 3000.)

node bin/www

Now if we navigate to http://localhost:3000 in the browser, we’ll see a basic Express app that just says “Welcome to Express.”


You can either add Airbrake to your dependencies or use yarn or npm to install airbrake. We’ll already have a package.json file in our Express app, so we can simply add a line at the bottom of our dependencies specifying airbrake and a target version:

  "name": "sample-app",
  "version": "0.0.0",
  "private": true,
  "scripts": {
    "start": "node ./bin/www"
  "dependencies": {
    "body-parser": "~1.17.1",
    "cookie-parser": "~1.4.3",
    "debug": "~2.6.3",
    "express": "~4.15.2",
    "jade": "~1.11.0",
    "morgan": "~1.8.1",
    "serve-favicon": "~2.4.2",
    "airbrake": "^2.1.0"

Of course current version numbers and specific dependencies may have changed in this file, but the concept is the same. They key is to add airbrake, in this case as the last line of the dependencies. Once this file is updated, we can just run yarn (or npm install) again in our main app directory to update our app.


Now all we need to do is add the sample Express airbrake code near the top of our app source file app.js, after our app variable has been defined. Airbrake can take advantage of the built-in error handling provided by Express versions as early as 2.x.

var airbrake = require('airbrake').createClient(

Airbrake will provide you with a project id and an api key, and will include them in the sample code they provide once you’ve logged into your account. Now the errors that would normally be caught by Express, as well as any other errors your code may generate, will be caught and tracked by Airbrake.

Checking Our Error Monitoring

For example, let’s see what happens when JavaScript throws an error. We can add code to throw a new Error into the default route handler in our routes/index.js file to trigger a JavaScript error, and see how it is tracked:

var express = require('express');
var router = express.Router();
/* GET home page. */
router.get('/', function(req, res, next) {
  res.render('index', { title: 'Express' });
  throw new Error('I am an uncaught exception');
module.exports = router;

If this were a regular production site, the first thing we might notice when the homepage generates that error is an email message from Airbrake, or possibly a notification in Slack or some other supported alert system. Airbrake lets you easily customize how frequently alerts of various kinds are sent, where they should go, and what events should trigger a notification.

With the default account settings, we would receive an email at the developer’s account with an overview of the error that occurred. In this case, it would include a warning that this is the first time this error has been encountered.


Next we can visit our Airbrake dashboard and see the error reflected in our reports, along with a lot of useful information including the custom message we created, when the error occurred, where it came from, the specific url and host, and how many times it’s happened. (Just once so far.)


Visiting the “Occurrences” tab on the dashboard will show us a backtrace from our server code to help us debug when and where the error might have been triggered in our code.


Expanding the “Environment” section of the tab will show us a number of useful details about our server and the processes that were running when the error occurred.


More information can be found by expanding the “Context” section of the tab, telling us about the operating environment our scripts were running in when the error happened.


Your App’s New Best Friend

Imagine that level of error coverage spread out over your entire user base, tracking every error on your app your users encounter in a production environment, and tabulating the results.

You can easily see how helpful this kind of information might be in a real-world production environment where users aren’t seeing what you want them to see. And thanks to the complete and detailed reports, think about how much time, money, and frustration you could save.

With Airbrake’s remote error tracking, you won’t have to wait for your friends to tell you when something’s wrong with your app. You’ll already know.