Environments and Versions

Honeybadger groups errors by the environment they belong to. You don’t have to set an environment, but it can be useful if you’re running your app in different locations, such as "production" and "staging".

To set the environment in Honeybadger:

javascript
Honeybadger.configure({ // ... environment: 'production' });

Honeybadger does not set the environment automatically; if you’re already using NODE_ENV, you should configure Honeybadger like this:

javascript
Honeybadger.configure({ // ... environment: process.env.NODE_ENV });

See Configuring with Environment Variables for tips on how to configure Honeybadger with environment variables.

Development Environments

Some environments should not report errors at all, such as when you are developing on your local machine or running your test suite (locally or in CI). By default, honeybadger.js does not report errors from the following environments:

dev development test

Honeybadger does not report errors in these environments unless you explicitly enable data reporting:

js
Honeybadger.configure({ reportData: true });

You can also define your own list of development environments:

js
Honeybadger.configure({ developmentEnvironments: ['my-environment'] });

Versions

It’s not uncommon for multiple versions of a client-side application to report errors at the same time, especially as a new version is rolled out. It’s important to tell Honeybadger which version of your application is currently deployed so that we can associate the error with the correct deploy and apply the correct source map to the stack trace.

Honeybadger uses the revision option to track the current version of your application. While this can be any unique value (such a “v1.2.3”), we prefer to use the Git SHA of the last commit (or the equivalent value from your source control management system):

javascript
Honeybadger.configure({ // ... revision: 'dcc69529edf375c72df39b0e9195d60d59db18ff' });

If you don’t configure the revision, Honeybadger defaults to “master”.

Configuring the revision from Git

The simplest way to get the SHA of the current Git commit is by assigning it to an environment variable before building your project:

sh
HONEYBADGER_REVISION=$(git rev-parse HEAD) \ npm build # your normal build command (could also be yarn, webpack, etc.)

The HONEYBADGER_REVISION environment variable can be accessed with process.env.HONEYBADGER_REVISION in Node.js (and $HONEYBADGER_REVISION in other shell scripts):

javascript
Honeybadger.configure({ // ... revision: process.env.HONEYBADGER_REVISION });

See Configuring with Environment Variables for tips on how to configure Honeybadger with environment variables.

You can also get the current Git SHA from inside Node.js, if you prefer:

javascript
const revision = require('child_process').execSync("git rev-parse HEAD").toString().trim();

Configuring the revision on Netlify

Netlify provides the current commit SHA in the COMMIT_REF environment variable:

javascript
Honeybadger.configure({ // ... revision: process.env.COMMIT_REF });

See Build environment variables in Netlify’s docs for additional Git metadata that is available at build-time; for tips on how to configure Honeybadger with environment variables, see Configuring with Environment Variables.