Error reporting tool presentWhat it checks and how to fix it

What it checks

Looks at the rendered homepage for a JavaScript error-reporting service: Sentry, Bugsnag, Rollbar, Airbrake, LogRocket, TrackJS, Raygun, Honeybadger, AppSignal or New Relic Browser. It passes when one is found; it warns when the page only has its own window.onerror or error-boundary handling, or when there is no error reporting at all.

Why it matters

JavaScript errors happen in your visitors' browsers, not on your server, so your logs never see them. A broken checkout button on one browser version or a third-party script that throws stays invisible until a customer complains, if they bother. An error-reporting service captures each exception with its stack trace, browser and page, groups them and alerts you, so you fix them before they cost you users.

How to fix it

Load an error-reporting SDK as early as possible on every page, so it catches errors thrown by the scripts that follow. A hand-written window.onerror that only logs to the console does not count: nobody reads your visitors' consoles.

Sentry from its loader script:

<script src="https://js.sentry-cdn.com/<your-public-key>.min.js" crossorigin="anonymous"></script>

Or from npm:

import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://<key>@o0.ingest.sentry.io/<project>",
  environment: "production"
});

Honeybadger, Bugsnag, Rollbar and the others work the same way: install the browser package, initialise it with your project key, and upload source maps on deploy so the stack traces point at your real code.