Errors
The Errors page of RUM Monitoring shows the JavaScript errors and failed file loads that real visitors hit, grouped into problems you can mark as fixed.
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
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
- RUM Monitoring needs the RUM script on your pages. See Install the 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
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 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.
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 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
| 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
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
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 anAccess-Control-Allow-Originheader. 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
When you release a fix, mark the problem as fixed. Then you can see if the error comes back.
- Click the problem in the Problems view.
- 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 (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
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
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?
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"?
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"?
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?
Only workspace owners and admins can mark a problem as fixed. Members do not see the button. Ask an owner or admin. See Members.
Related
- Overview - filters, devices and page-view limits
- Page Views - the full details of one visit
- Alerts - get a message when errors increase
- Install the RUM script - the script that catches the errors
Engagement
The Engagement page of RUM Monitoring shows whether visitors read, click, fill in forms and stay less on slow pages than on fast ones.
Page Views
The Page Views page of RUM Monitoring lists each real visit with its speed numbers, and opens one visit with its timeline, metrics, files and environment.
