Error tracking troubleshooting and FAQs

FAQs

How much does error tracking cost?

Your first 100,000 $exception events each month are free – i.e. if you never exceed this number, you can use error tracking for free.

After this, we charge a small amount for each $exception event you send. The more events you send, the less each event costs.

Go to the pricing page to use our calculator to get an estimate. You can also view an estimate on your billing page.

Are web workers supported?

Yes. Error tracking will work as long as you initialize PostHog in the web worker. You will need to disable any features that rely on the window object:

posthog.init(token, {
    ...
    autocapture: false,
    capture_pageview: false,
    capture_pageleave: false,
    disable_session_recording: true,
    disable_surveys: true,
});

To identify users in web workers you will need to pass the distinct ID. This can be done via an env variable or sending it via postMessage from your main application.

Can exceptions be sampled / ignored

Returning null for a given event in the before_send hook will cause it not to be captured. You may want to:

• Drop certain types of exceptions
• Randomly sample a subset of all exceptions
• Sample based on the events properties (e.g. URL or user)

Troubleshooting

What is a 'Script error.' with no stack traces?

For security purposes, errors sent from a JavaScript file served on a different domain hide the original error to avoid unintentionally leaking sensitive information to any onerror handler. This is often the case for third party scripts running on a site and results in an obfuscated 'Script error.' with no associated stack trace.

To see the actual error, the erroring script needs to be loaded anonymously which excludes potentially user-identifying information such as cookies from being transmitted when requesting the file.

<script src="https://third-party.domain/script.js" crossorigin="anonymous"></script>

It can be somewhat difficult to know which script is causing the error because the captured exception provides no context. There is no solution to this other than to work through a process of elimination.

If the script is within your control, you also need to set the Access-Control-Allow-Origin response header to include the calling domain. This can be a comma separated list of valid domains or a global wildcard e.g *.

What is a 'Non-Error promise rejection' error with no stack traces?

When you do not pass an Error object to a rejected promise, the resulting error captured will be a generic 'Non-Error promise rejection' and the stack trace context will not be included. An example of this is:

new Promise((resolve, reject) => {
    // the captured error will be 'Non-Error promise rejection' without a stack trace
    reject('Something went wrong');
});

The easiest way to resolve this is to always reject promises with an Error object:

new Promise((resolve, reject) => {
    // the captured error will be 'Something went wrong' with a stack trace
    reject(new Error('Something went wrong'));
});

What is a 'Minified React error' with no stack traces?

In order to reduce bundle size in production builds React removes useful debugging information from errors thrown by the framework. This results in errors that lack stack traces and look like the following:

Minified React error #123; visit https://reactjs.org/docs/error-decoder.html?invariant=123 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

The link provided in the error message can be used to look up the full error message and understand the cause of the error. However, it will not tell you exactly where in your code the error originates from.

One way to debug these kinds of issues is to watch session recordings to see what user actions lead up to the error occurring. From there you can try to reproduce the error by following the same steps in your development environment, where the full stack trace will be available.