Non-Error promise rejection captured: what it means and how to fix it

What it means

A promise was rejected with something that is not an Error object, such as undefined, a string, a plain object or a DOM Event, and nothing caught it. Without an Error there is no stack, so the SDK reports the value it got.

Common sources are libraries that reject with a plain object, code that calls reject() with no argument, and browser APIs that reject with an Event.

Is it a real bug?

Sometimes: an unhandled rejection is a missing catch. But the report has no stack, so you cannot tell where it came from, and a large share come from third-party scripts and browser extensions.

In your own code, always reject with new Error(...) and add a catch where you start the promise. Then the real ones arrive with a stack and you can filter the rest.

How to filter it

For any Sentry-compatible browser SDK:

Sentry.init({
  dsn: "...",
  ignoreErrors: [
    /^Non-Error promise rejection captured/,
    /^Object captured as promise rejection with keys/,
  ],
});

In RealUptime Errors

You do not need the filter above. RealUptime Errors drops this error by default, before it reaches your quota, and counts every drop on the issue list so nothing disappears silently. What we match: The Sentry SDK wording for non-Error rejections, and, from the RealUptime SDK, a rejection value of undefined, null or [object Object] with no type and no stack.

To see these errors anyway, turn off the noise filter for a project in Errors settings. It works the same for the RealUptime SDK and for Sentry SDKs pointed at RealUptime.

Try Errors free Other noise errors