# RUM Monitoring: Errors

The **Errors** page of RUM Monitoring shows the JavaScript errors and the files that failed to load on real visits. It groups the same errors into problems, so that one fix can clear many reports.

## What RUM Monitoring records as an error [#what-rum-monitoring-records-as-an-error]

The RUM script catches errors in the visitor's browser. No server log can see these errors. The script records three types of error:

| Type | What it is |
|---|---|
| **JavaScript** | An error in a script of the page that the code did not catch |
| **Resource** | A file that the page asked for and the browser could not load, for example an image, a script or a stylesheet |
| **Unhandled rejection** | A failed promise (a background task in a script) that no code handled |

A failed request to a server shows here only when it causes an uncaught error or an unhandled rejection.

RUM Monitoring hides personal data in error messages and stack traces. Email addresses, card numbers and similar values show as placeholders, for example `[EMAIL]` or `[CARD]`.

## Before you start [#before-you-start]

- RUM Monitoring needs the RUM script on your pages. See [Install the RUM script](/connect/rum-script).
- In the sidebar, open **Web performance** > **RUM Monitoring** > **Errors**.
- Select **Phone** or **Desktop** in the filter dock. The Errors page shows the errors of the selected device only.
- Only workspace owners and admins can mark a problem as fixed. Members see the Errors page read-only.

## Filters on the Errors page [#filters-on-the-errors-page]

The Errors page has the normal RUM Monitoring filters: date, compare, **URL Path**, **Country** and **Browser**. It also has three filters on the error itself:

- **Error type:** **JavaScript**, **Resource** or **Unhandled rejection**.
- **Error message:** a text match on the message.
- **Operating system:** for example **Android**, **iOS**, **Windows**, **macOS**, **Linux** or **ChromeOS**.

The filters on the error itself change only the list of problems and events. They do not change the tiles and the chart of **Errors over time**.

In the **Problems** view, the dock also has a **Problems** control: **Open** (the default), **Fixed** or **All**. **Open** also shows problems that came back after you marked them as fixed.

## The Errors verdict [#the-errors-verdict]

The verdict is one sentence at the top of the Errors page. It shows when 2% or more of the visits hit an error. For example: "On Phone, 3.4% of visits hit an error".

The verdict is orange from 2% and red from 10%. Below 2%, the page shows no verdict.

If Site Health Monitoring found issues about your errors, a banner shows their number. Click **Open in Site Health Monitoring** to see them. See [Site Health Monitoring](/site-health/overview).

## Errors over time [#errors-over-time]

The **Errors over time** card has three tiles. Click a tile to show its chart.

| Tile | What it shows |
|---|---|
| **Visits with an error** | The share of visits that hit at least one error, with "N of N visits" |
| **Errors** | Every error event captured. One visit can hit the same error many times. |
| **Visits measured** | Page loads that measured a Core Web Vital or hit an error: the base of the share |

**Visits with an error** is green below 2%, orange from 2% and red from 10%. **Visits measured** shows if a drop in errors comes from a drop in traffic.

The chart shows the selected tile day by day. Use the **Day**, **Week** or **Month** control to group it. This chart has no **Hour** option. With compare on, a dashed line shows the earlier period. A jump on one day often points to a release.

## The Problems view [#the-problems-view]

The **Problems** view groups the same error into one problem. It is the default view of the card. Use the **Problems** and **Events** switch at the top right of the card to change the view.

| Column | What it shows |
|---|---|
| **Problem** | The name of the error, for example "Script error" or "Stylesheet failed to load" |
| **Type** | **JavaScript**, **Resource** or **Unhandled rejection** |
| **Status** | **Open**, **Fixed** or **Came back** |
| **Visits affected** | The visits that hit the problem |
| **Errors** | How many times the problem fired |
| **Last seen** | When the problem last fired |

By default, the problems that affect the most visits come first. Click **Visits affected**, **Errors** or **Last seen** to sort. The table shows 20 problems on each page of results.

### Problem status [#problem-status]

| Status | What it means |
|---|---|
| **Open** | Nobody marked the problem as fixed |
| **Fixed** | Someone marked it as fixed, and it did not fire again |
| **Came back** | Someone marked it as fixed, but it fired again after that |

A promise that failed with no reason shows as "Promise rejected without a reason".

## Open a problem [#open-a-problem]

Click a problem to open its side panel. The header shows the name, the status, the dates **First seen** and **Last seen**, and the type. Use the arrows to move to the next or the previous problem.

The side panel has four tabs:

- **Summary:** the tiles **Visits affected**, **Errors** and **Pages**, the fix date if any, and advice.
- **Pages:** the pages where the problem fired, with **Visits** and **Errors** for each.
- **Browsers and countries:** the browsers and the countries where it fired, with **Visits** and **Errors**.
- **Examples:** the latest single errors of the problem, with all their details. It shows 10 examples on each page.

### Advice in the Summary tab [#advice-in-the-summary-tab]

For three kinds of problem, the **Summary** tab explains the cause and gives a **What to do** line:

- **"Script error":** a script from another site failed, and the browser hides the details. Add `crossorigin="anonymous"` to that script tag. Make its server send an `Access-Control-Allow-Origin` header. Then the real message shows.
- **A file that failed to load:** the browser could not fetch a file. It is missing, blocked, or its address is wrong. Open an example, check the address, and fix or remove the reference.
- **"Failed to fetch", "NetworkError" or "Load failed":** a request to a server failed. Check that the server is up and sends the correct CORS headers.

Other problems get no advice, because VitalSentinel does not guess the cause.

## Mark a problem as fixed [#mark-a-problem-as-fixed]

When you release a fix, mark the problem as fixed. Then you can see if the error comes back.

1. Click the problem in the **Problems** view.
2. In the side panel, click **Mark as fixed**.

The toast says: 'Marked as fixed. It shows as "Came back" if it fires again.' The **Summary** tab then says "Marked as fixed on" the date, and "Nothing has fired since."

If the error fires again, the status changes to **Came back**. The **Summary** tab shows the date it fired again. To undo the change, click **Mark as open again**.

## The Events view [#the-events-view]

The **Events** view (title **Every error**) lists each single error, newest first. It has these columns:

| Column | What it shows |
|---|---|
| **Error** | The error message |
| **Type** | **JavaScript**, **Resource** or **Unhandled rejection** |
| **Page** | The page where the error happened |
| **Environment** | The browser and the operating system, for example "Chrome on Windows" |
| **When** | The date and time of the error |

Click a row to open the error in a side panel. The table shows 20 errors on each page of results.

## Details of one error [#details-of-one-error]

The side panel of one error, and each example of a problem, has three sections.

**The error** shows **Type**, **Message** and **When**. For a resource error, it also shows **Resource address** and **Element**. For a script error, **Source** shows the file, the line and the column. If the element points to the page itself, a warning says that the browser fetched an HTML page instead of a file.

**Where it happened** shows **Page**, **Came from** (the previous page), **Browser**, **Operating system**, **Device** and **Country**.

**Stack trace** shows the list of code calls that led to the error, when the browser reported one. The last line shows the visit ID.

## Troubleshooting [#troubleshooting]

### Why does the Errors page show "Script error" with no details? [#why-does-the-errors-page-show-script-error-with-no-details]

The error came from a script on another site. The browser hides the details of such errors. Add `crossorigin="anonymous"` to the script tag, and make its server send an `Access-Control-Allow-Origin` header.

### Why do the error filters not change the Errors over time chart? [#why-do-the-error-filters-not-change-the-errors-over-time-chart]

The **Error type**, **Error message** and **Operating system** filters change only the list. The tiles and the chart use the visit totals, which know only **URL Path**, **Country** and **Browser**.

### Why does a problem I fixed show "Came back"? [#why-does-a-problem-i-fixed-show-came-back]

The error fired again after the date that someone marked it as fixed. The fix did not work for all visitors, or old pages in browser caches still run the old code. Open the **Examples** tab to see the new errors.

### Why does the Errors page say "No open problems in this period"? [#why-does-the-errors-page-say-no-open-problems-in-this-period]

No open problem fired in the selected dates and filters. Select **All** in the **Problems** control of the dock to see fixed problems too.

### Why can I not click Mark as fixed? [#why-can-i-not-click-mark-as-fixed]

Only workspace owners and admins can mark a problem as fixed. Members do not see the button. Ask an owner or admin. See [Members](/workspace/members).

## Related [#related]

- [Overview](/rum-monitoring/overview) - filters, devices and page-view limits
- [Page Views](/rum-monitoring/page-views) - the full details of one visit
- [Alerts](/domain/alerts) - get a message when errors increase
- [Install the RUM script](/connect/rum-script) - the script that catches the errors