|
1 | 1 | --- |
2 | | -title: Error tracking troubleshooting and FAQs |
| 2 | +title: Error Tracking troubleshooting |
3 | 3 | --- |
4 | 4 |
|
5 | | -## FAQs |
| 5 | +This page covers troubleshooting for Error Tracking. For setup, see the [installation guides](/docs/error-tracking/installation). |
6 | 6 |
|
7 | | -### How much does error tracking cost? |
| 7 | +## Have a question? Ask PostHog AI |
8 | 8 |
|
9 | | -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. |
| 9 | +<AskAIInput placeholder="Type your question and hit enter..." /> |
10 | 10 |
|
11 | | -After this, we charge a small amount for each `$exception` event you send. The more events you send, the less each event costs. |
| 11 | +## Exceptions not appearing |
12 | 12 |
|
13 | | -Go to the [pricing page](/pricing) to use our calculator to get an estimate. You can also view an estimate on [your billing page](https://us.posthog.com/organization/billing). |
| 13 | +If PostHog isn't capturing errors: |
14 | 14 |
|
15 | | -### Are web workers supported? |
| 15 | +1. Use the [SDK Doctor](/docs/sdk-doctor) to verify your SDKs are updated to the latest version |
| 16 | +2. Verify **exception capture** is enabled in [project settings](https://app.posthog.com/settings/project-error-tracking#exception-autocapture) |
| 17 | +3. Only unhandled exceptions auto-capture. For caught errors, use `posthog.captureException()`: |
16 | 18 |
|
17 | | -Yes. Error tracking will work as long as you initialize PostHog in the [web worker](/tutorials/web-worker). You will need to disable any features that rely on the `window` object: |
| 19 | + ```js |
| 20 | + try { |
| 21 | + // code that errors |
| 22 | + } catch (error) { |
| 23 | + posthog.captureException(error) |
| 24 | + } |
| 25 | + ``` |
18 | 26 |
|
19 | | -```js |
20 | | -posthog.init(token, { |
21 | | - ... |
22 | | - autocapture: false, |
23 | | - capture_pageview: false, |
24 | | - capture_pageleave: false, |
25 | | - disable_session_recording: true, |
26 | | - disable_surveys: true, |
27 | | -}); |
28 | | -``` |
| 27 | +4. Wait a few minutes and check [Error Tracking in the PostHog app](https://app.posthog.com/error_tracking). Issues may take a few minutes to update after ingesting new error events |
| 28 | + |
| 29 | +## Source maps not resolving |
| 30 | + |
| 31 | +If stack traces show minified code instead of original source: |
| 32 | + |
| 33 | +1. Verify source maps are uploaded to the correct project by navigating to [Error Tracking](https://app.posthog.com/error_tracking) and selecting **Configure** > **Symbol sets**. You'll also see warnings for missing symbol sets |
| 34 | +2. The `release` tag in your SDK config must match the version you uploaded: |
29 | 35 |
|
30 | | -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. |
| 36 | + ```js |
| 37 | + posthog.init('<ph_project_api_key>', { |
| 38 | + ... |
| 39 | + session_recording: { |
| 40 | + recordCrossOriginIframes: true, |
| 41 | + }, |
| 42 | + release: 'v1.2.3' |
| 43 | + }) |
| 44 | + ``` |
31 | 45 |
|
32 | | -### Can exceptions be sampled / ignored |
| 46 | +3. Source map paths must match your production bundle URLs exactly |
| 47 | +4. Upload source maps *before* deploying code that references them |
33 | 48 |
|
34 | | -Returning `null` for a given event in the [`before_send`](/docs/libraries/js/features#amending-or-sampling-events) hook will cause it not to be captured. You may want to: |
35 | | -- Drop certain types of exceptions |
36 | | -- Randomly sample a subset of all exceptions |
37 | | -- Sample based on the events properties (e.g. URL or user) |
| 49 | +See the [source maps guide](/docs/error-tracking/upload-source-maps/) for upload instructions. |
38 | 50 |
|
39 | | -## Troubleshooting |
| 51 | +## 'Script error' with no stack trace |
40 | 52 |
|
41 | | -### What is a 'Script error.' with no stack traces? |
| 53 | +For security purposes, browsers hide error details from scripts loaded from different domains. This shows as `Script error` with no stack trace. |
42 | 54 |
|
43 | | -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. |
| 55 | +To fix, add `crossorigin="anonymous"` to your script tags: |
44 | 56 |
|
45 | | -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. |
| 57 | +```html |
| 58 | +<script src="https://your-cdn.com/app.js" crossorigin="anonymous"></script> |
| 59 | +``` |
| 60 | + |
| 61 | +If the script is within your control, also set the `Access-Control-Allow-Origin` response header to your origin: |
46 | 62 |
|
47 | 63 | ``` |
48 | | -<script src="https://third-party.domain/script.js" crossorigin="anonymous"></script> |
| 64 | +Access-Control-Allow-Origin: https://yourdomain.com |
49 | 65 | ``` |
50 | 66 |
|
51 | | -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. |
| 67 | +Or allow any origin: |
| 68 | + |
| 69 | +``` |
| 70 | +Access-Control-Allow-Origin: * |
| 71 | +``` |
52 | 72 |
|
53 | | -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 `*`. |
| 73 | +You can also use [session recordings](/docs/session-replay) to see what user actions triggered the error. |
54 | 74 |
|
55 | | -### What is a 'Non-Error promise rejection' error with no stack traces? |
| 75 | +## 'Non-Error promise rejection' with no stack trace |
56 | 76 |
|
57 | | -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: |
| 77 | +This happens when you reject a promise with a string instead of an `Error` object. Without an `Error` object, there's no stack trace to capture. |
58 | 78 |
|
59 | | -```js |
| 79 | +<MultiLanguage> |
| 80 | + |
| 81 | +```js file=Without stack trace |
60 | 82 | new Promise((resolve, reject) => { |
61 | | - // the captured error will be 'Non-Error promise rejection' without a stack trace |
62 | | - reject('Something went wrong'); |
| 83 | + reject('Something went wrong'); // String has no stack trace |
63 | 84 | }); |
64 | | -``` |
65 | 85 |
|
66 | | -The easiest way to resolve this is to always reject promises with an `Error` object: |
| 86 | +Promise.reject('Something went wrong'); |
| 87 | +``` |
67 | 88 |
|
68 | | -```js |
| 89 | +```js file=With stack trace |
69 | 90 | new Promise((resolve, reject) => { |
70 | | - // the captured error will be 'Something went wrong' with a stack trace |
71 | | - reject(new Error('Something went wrong')); |
| 91 | + reject(new Error('Something went wrong')); // Error includes stack trace |
72 | 92 | }); |
| 93 | + |
| 94 | +Promise.reject(new Error('Something went wrong')); |
| 95 | +``` |
| 96 | + |
| 97 | +</MultiLanguage> |
| 98 | + |
| 99 | +For third-party libraries that reject with strings, wrap the rejection: |
| 100 | + |
| 101 | +```js |
| 102 | +somePromise() |
| 103 | + .catch(err => { |
| 104 | + posthog.captureException(new Error(err)) |
| 105 | + throw err |
| 106 | + }) |
73 | 107 | ``` |
74 | 108 |
|
75 | | -### What is a 'Minified React error' with no stack traces? |
| 109 | +## 'Minified React error' with no stack trace |
76 | 110 |
|
77 | | -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: |
| 111 | +In production builds, React removes debugging information to reduce bundle size. Errors look like: |
78 | 112 |
|
79 | 113 | ``` |
80 | | -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. |
| 114 | +Minified React error #123; visit https://reactjs.org/docs/error-decoder.html?invariant=123 |
81 | 115 | ``` |
82 | 116 |
|
83 | | -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. |
| 117 | +To debug: |
| 118 | + |
| 119 | +1. Upload source maps to get readable stack traces. See the [source maps guide](/docs/error-tracking/upload-source-maps/) |
| 120 | +2. Visit the error URL in the message to understand what went wrong |
| 121 | +3. Watch [session recordings](/docs/session-replay) to see what user actions triggered the error, then reproduce in development |
| 122 | +4. Use a development build which includes full error messages. Only use this for debugging, not production |
| 123 | + |
| 124 | +## Solved community questions |
84 | 125 |
|
85 | | -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. |
| 126 | +<SolvedQuestions |
| 127 | + topicLabel="Error Tracking" |
| 128 | + pinnedQuestions={[ |
| 129 | + 'code-variables-for-external-libraries-for-python', |
| 130 | + 'trouble-setting-up-source-map-in-vite-react', |
| 131 | + 'webpack-turbopack-plugin-getting-sourcemaps-uploaded-to-vercel' |
| 132 | + ]} |
| 133 | +/> |
0 commit comments