Getting started

To get started, globally install the debugbear Node module and generate an API key. You'll also need to know the ID of the page you want to test.

Read more about getting set up.

Running a normal test on the monitored page

The command below will test the page and show it in the normal results view.

DEBUGBEAR_API_KEY=... debugbear --pageId=... --waitForResult

The output will look like this:

Repo: not specified
Commit: not specified
When the result is ready you can see it here:
Waiting for result
Build complete

Running tests in CI

To run DebugBear as part of CI you either need to deploy the CI build to a public server or use a tool like ngrok to make the local server accessible.

If you customize a build it will not show up as part of the continuous monitoring of your live site, but will only show up as a build or on the branch. Customization could mean passing in a URL, tweaking the login details, or passing in custom headers. (This only applies if your test has a commitHash.)

The base build is either the latest daily monitoring result, or the latest build on a base branch, if --baseBranch is passed into the CLI and a build on that branch is available.

debugbear \
  --pageId=... \
  --commitHash=fd9aed3 \
  --commitBranch=my-feature-branch \
  --buildTitle="Commit message" \
  --baseBranch=master \

Often these options can be inferred using env-ci, so you usually don't need to pass in --commitHash, --commitBranch, or --buildTitle. To enable this feature pass in the --inferBuildInfo flag.

DebugBear monitoring result for two tests, on on master and one on my-feature-branch

Running tests in CI with ngrok

If you aren't deploying your build to a staging server you can use your CI environment as one. You can use ngrok to expose your CI environment publicly.

When running debugbear, pass in the --ngrokWebPort=4040 option. This lets DebugBear find out the domain name of your server. The pathname will be take from the monitored page, or you can use --path=/somewhere to override it.

Make sure to also pass in --waitForResult to keep your CLI server up until the test has finished.

You can read a more detailed how-to guide here.

CLI options

This is the full list of available CLI options.

Option Name Description
...url Override the URL that's tested
--pageId Which of the pages in your project the tested page belongs to
--waitForResult [CLI only] Don't exit CLI command until the test has finished
--inferBuildInfo Infer commit hash, commit branch, build title, base branch, and base hash from the local version control environment and the environment variables of the CI system
--commitHash Hash of the commit being built, used for build comparison and Github integration
--commitBranch Branch that's being built, used for build comparison and Github integration
--buildTitle Name of the build, defaults to the git commit message
--baseBranch Branch to compare the commit to, usually something like master or develop
--baseHash Commit hash to compare the commit to
--repoOwner Used for Github integration, username or organization that owns the repo
--repoName Used for Github integration, name of the git repo
--ngrokWebPort Port for the ngrok admin interface, usually 4040
--path Pathname of the page if different than what the --pageId page uses
--customHeader Extra HTTP header to be sent for each request, formatted as headerName:headerValue. The node API uses a customHeaders object instead, e.g. {a: "b"}
--userFlowReplacement Replace values in a user/setup flow, e.g change login details to your staging server. Formatted as search:replacement. The node API uses a userFlowReplacements object instead, e.g. {a: "b"}
--fail Return a non-zero status code if the build status is failure. Use in combination with --waitForResult

Still need help? Contact for support.
DebugBear is a website monitoring tool built for front-end teams. Track performance metrics and Lighthouse scores in CI and production. Learn more.