# RUM Monitoring: Overview

RUM Monitoring (Real User Monitoring) measures how fast your site is for the people who really visit it. The **Overview** page shows the Core Web Vitals of your real visitors and the pages that hold them back.

## What RUM Monitoring does [#what-rum-monitoring-does]

RUM Monitoring uses a small script on your pages. The script measures each page load in the visitor's own browser, on their own device, network and location. So the numbers come from real visits, not from a lab test.

RUM Monitoring records three kinds of data:

- **Speed:** the five metrics LCP, INP, CLS, FCP and TTFB for each page load.
- **Errors:** JavaScript errors and files that failed to load in the visitor's browser.
- **Engagement:** scrolling, clicks, forms and time on the page.

RUM Monitoring is different from the two other speed modules. [Synthetic Monitoring](/synthetic-monitoring/overview) runs lab tests from a clean, controlled machine. [CrUX Monitoring](/crux-monitoring/overview) shows Google's real-user data, which covers Chrome visits only, has a delay of weeks and covers only pages with enough Chrome traffic. RUM Monitoring covers every visitor and every page, with data in minutes.

## Core Web Vitals [#core-web-vitals]

Core Web Vitals are three speed metrics from Google. Google uses them to judge the page experience of a site. RUM Monitoring shows them together with two more metrics that help explain them.

| Metric | What it measures | Core Web Vital |
|---|---|---|
| LCP (Largest Contentful Paint) | How long until the main content is on screen | Yes |
| INP (Interaction to Next Paint) | How quickly the page reacts to a tap, click or key press | Yes |
| CLS (Cumulative Layout Shift) | How much the page jumps while it loads | Yes |
| FCP (First Contentful Paint) | How long until the first text or image appears | No |
| TTFB (Time to First Byte) | How long your server takes to start its answer | No |

Each metric has its own page in the sidebar. See [LCP](/rum-monitoring/lcp), [INP](/rum-monitoring/inp), [CLS](/rum-monitoring/cls), [FCP](/rum-monitoring/fcp) and [TTFB](/rum-monitoring/ttfb).

## Good, Needs improvement and Poor [#good-needs-improvement-and-poor]

RUM Monitoring rates each value in one of three bands: **Good**, **Needs improvement** or **Poor**. The bands use Google's limits. Green means Good, orange means Needs improvement and red means Poor.

| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 s or less | 4 s or less | More than 4 s |
| INP | 200 ms or less | 500 ms or less | More than 500 ms |
| CLS | 0.1 or less | 0.25 or less | More than 0.25 |
| FCP | 1.8 s or less | 3 s or less | More than 3 s |
| TTFB | 800 ms or less | 1.8 s or less | More than 1.8 s |

For more about each band, see [Metrics and thresholds](/help/metrics-and-thresholds).

### What the headline value means [#what-the-headline-value-means]

The headline value of a metric in RUM Monitoring is the value of a typical visit. For LCP, 3 out of 4 page loads were this fast or faster. For CLS, 3 out of 4 page loads shifted this much or less. Google uses the same statistic, so you can compare the two.

### How Google judges a Core Web Vital [#how-google-judges-a-core-web-vital]

Google judges LCP, INP and CLS each on its own. A metric passes when at least 3 out of 4 page loads are Good. RUM Monitoring shows this as **Good visits**, the share of visits rated Good. A Core Web Vital passes at 75% Good visits.

### Small samples [#small-samples]

A figure from fewer than 30 visits describes the sample, not your site. RUM Monitoring then shows the figure in a neutral color without a rating, with a note such as **Only 12 visits**. A table cell shows a dash with a note such as "Fewer than 30 visits measured LCP on Phone."

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

- **Verified domain:** RUM Monitoring collects no data until you verify that you own the domain. Until then, the page shows **Waits for verification**. See [Verify ownership](/getting-started/domain-setup/verify-ownership).
- **Script:** RUM Monitoring needs the RUM script on your pages. See [Install the RUM script](/connect/rum-script).
- **Plan:** RUM Monitoring is on every plan. Your plan sets how many page views RUM Monitoring stores each month for the workspace. See [Page-view limits](#page-view-limits).
- **Role:** Workspace owners and admins can install the script and mark errors as fixed. Members see the RUM Monitoring pages read-only.
- **Where:** In the sidebar, open **Web performance** > **RUM Monitoring**.

## The RUM Monitoring pages [#the-rum-monitoring-pages]

The RUM Monitoring item in the sidebar has nine pages:

| Page | What it shows |
|---|---|
| [Overview](/rum-monitoring/overview) | The Core Web Vitals of the site, the slow pages and the countries |
| [LCP](/rum-monitoring/lcp) | When the main content shows, its phases, the largest element and its files |
| [CLS](/rum-monitoring/cls) | How much pages jump, when shifts happen and what moves |
| [INP](/rum-monitoring/inp) | How fast pages react, its phases and the scripts that slow taps |
| [FCP](/rum-monitoring/fcp) | When anything first appears |
| [TTFB](/rum-monitoring/ttfb) | How fast your server answers, and where the wait goes |
| [Engagement](/rum-monitoring/engagement) | Whether visitors read, click and fill in forms less on slow pages |
| [Errors](/rum-monitoring/errors) | JavaScript errors and failed file loads, grouped into problems |
| [Page Views](/rum-monitoring/page-views) | Each real visit with its speed numbers and details |

## Where the data comes from [#where-the-data-comes-from]

Numbers appear in RUM Monitoring within minutes of the first real visit.

RUM Monitoring keeps out visits that are not real people:

- Declared bots, such as search engine crawlers, SEO tools and automated test browsers.
- Visits from the VitalSentinel crawler, which [Site Health Monitoring](/site-health/overview) and [Page Monitoring](/page-monitoring/overview) use.
- Visits to test addresses, such as `localhost` or an IP address.

So the visit count in RUM Monitoring can be lower than the hit count in your server logs.

### Privacy of the stored data [#privacy-of-the-stored-data]

RUM Monitoring replaces parts of an address that look like a code or a token before it stores the address. For example, a UUID shows as `:uuid` and a long token shows as `:id`. A normal record number, such as `/orders/44172`, stays as it is. A URL Path filter matches this stored form.

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

### How far back the data goes [#how-far-back-the-data-goes]

RUM Monitoring keeps data for 16 months on every plan. The date picker stops at the earliest date that RUM Monitoring keeps. See [Plans and limits](/workspace/plans-and-limits#how-long-vitalsentinel-keeps-your-data).

## Page-view limits [#page-view-limits]

Your plan sets how many page views RUM Monitoring stores each month. All domains in the workspace share this limit. The limit resets at the start of each billing cycle.

| Plan | RUM page views each month |
|---|---|
| Free | 25K |
| Starter | 100K |
| Lite | 250K |
| Standard | 2M |
| Advanced | 5M |

If the workspace reaches the limit, RUM Monitoring shows the banner **RUM Monitoring has reached this month’s limit**. The banner says: "Data collected so far stays. New data is not stored until the limit resets." A meter shows the page views used this month and the date of the reset.

The workspace owner sees **Compare plans**. Admins see **Ask your workspace owner**, which copies a message for the workspace owner. See [Billing](/workspace/billing).

## Filters and the device [#filters-and-the-device]

All RUM Monitoring pages share the filter dock at the bottom of the page. The dock keeps your choices when you move from one RUM Monitoring page to another. For how the dock works, see [Using the app](/getting-started/using-the-app).

### Device: Phone or Desktop [#device-phone-or-desktop]

The **Device** control in the dock has two options: **Phone** (the default) and **Desktop**. Google judges Core Web Vitals for each device type on its own. So every RUM Monitoring page shows one device at a time and has no "all devices" option. Tablets are in neither group.

### Date range [#date-range]

The default date range is the last 28 days. The presets are **Today**, **Yesterday**, the last 7, 28, 30 or 90 days, the last 6 or 12 months, this year and last year. You can also select your own dates.

### URL Path, Country and Browser filters [#url-path-country-and-browser-filters]

You can filter all RUM Monitoring pages by **URL Path**, **Country** and **Browser**. Each filter has these operators: **contains**, **equals**, **matches regex**, **matches any (batch)**, **doesn't contain**, **doesn't equal**, **doesn't match regex**, **doesn't match any (batch)**, **contains any of** and **contains none of**. **URL Path** also has **starts with**.

A batch operator takes one value on each line and matches the full value exactly. **contains any of** also takes a list, but it matches part of the value. You can join rules with And or Or, and put rules in groups.

The **Errors** page also has the filters **Error type**, **Error message** and **Operating system**. The **Page Views** page also has **Operating system**.

If RUM Monitoring cannot use a filter, the page shows "A filter can't be applied" with the reason. Change the filter in the dock, or click **Clear filters**.

### Compare with an earlier period [#compare-with-an-earlier-period]

Turn on compare in the dock to compare the selected dates with an earlier period. Then the tiles show a change chip, and the charts show the earlier period as a dashed line. Tables show the change next to each value. A change from too few visits shows a dash, not a percentage. The **Page Views** page has no compare.

## The Overview page [#the-overview-page]

The **Overview** page shows the Core Web Vitals of the whole site for the selected device. From top to bottom, it has a verdict, a link to Site Health Monitoring, the **Core Web Vitals on Phone** card, the **Where it is slow** card and the **Countries** card.

### The verdict [#the-verdict]

The verdict is one sentence at the top of the Overview. It shows only when a Core Web Vital fails or a metric needs work. For example:

- "On Phone, Core Web Vitals fail (LCP and INP)"
- "On Phone, Core Web Vitals pass; TTFB needs work"

The figures next to the sentence are the values of the metrics that it names. Hover a figure to see its band and limits. The verdict needs at least two of LCP, INP and CLS, each from 30 visits or more.

### The Site Health Monitoring banner [#the-site-health-monitoring-banner]

If Site Health Monitoring found issues or opportunities about RUM Monitoring data, a banner shows their number by severity. Click **Open in Site Health Monitoring** to see them. See [Site Health Monitoring](/site-health/overview).

### Core Web Vitals card: the tiles [#core-web-vitals-card-the-tiles]

The **Core Web Vitals on Phone** card (or **on Desktop**) has one tile for each figure. Click a tile to show its chart below.

- **Good visits:** the share of visits that were Good on LCP, INP and CLS at the same time. This is stricter than Google's test, which judges each metric on its own.
- **LCP**, **INP** and **CLS:** the typical value of each Core Web Vital, colored by its band.
- **More metrics:** this menu opens the **FCP** and **TTFB** tiles. Google does not judge these two metrics. They help explain LCP.

A metric tile without data shows **Not measured on Phone** (or **on Desktop**).

### Core Web Vitals card: the chart [#core-web-vitals-card-the-chart]

For a metric tile, the chart shows the typical value over time as an area. Two lines mark the **Good** limit and the **Poor** limit. With compare on, a dashed line shows the earlier period.

For the **Good visits** tile, the chart shows the share of **Good**, **Needs improvement** and **Poor** visits over time, stacked to 100%. Hover a point to see the number of visits. A point from fewer than 30 visits says "a small sample".

Use the **Hour**, **Day**, **Week** or **Month** control to group the chart. **Hour** is available for ranges of 7 days or less. **Week** starts at 14 days and **Month** at 60 days.

### Notes on the charts [#notes-on-the-charts]

Sometimes VitalSentinel changes what RUM Monitoring measures, or it calculates stored data again. Then a note shows on the chart, on the day of the change. Hover that day to read the note. Values before and after that day can be different for this reason, not because your site changed.

### Where it is slow [#where-it-is-slow]

The **Where it is slow** card lists the pages of the site for the selected device. By default, the pages that cost the most visits a Good experience come first. It has these columns:

| Column | What it shows |
|---|---|
| **Page** | The page address. The menu opens the page in other modules. |
| **Visits** | The visits to the page in the period |
| **Google clicks** | The clicks from Google web search, from Google Search Console |
| **Verdict** | **Pass** or **Fail** for the Core Web Vitals of the page |
| **LCP**, **INP**, **CLS** | The typical value of each metric, with its change when compare is on |
| **Visits affected** | The visits on the page that were not Good |

**Verdict** is **Pass** when the typical value is Good on every Core Web Vital that RUM Monitoring measured on the page. It is **Fail** when one is not Good. A page with fewer than 30 visits shows a dash.

### Where it is slow: sort and actions [#where-it-is-slow-sort-and-actions]

Click a column header to sort by **Visits**, **Google clicks**, a metric or **Visits affected**. The table shows 20 pages on each page of results.

**Google clicks** come from Google Search Console and have a delay of two to three days. If Google Search Console is not connected, the card shows **Connect Google Search Console**. See [Connect Google Search Console](/connect/search-console).

Owners and admins can click **Watch in Page Monitoring** on a row. Page Monitoring then checks that page on a schedule. See [Page Monitoring](/page-monitoring/overview).

### Countries [#countries]

The **Countries** card shows a world map for the selected device. Each country has the color of its rating: **Good**, **Needs improvement** or **Poor**. **Low sample** means too few visits to rate. **No data** means no visits.

On the Overview, a country is Poor if any of LCP, INP and CLS is Poor. It is Good only when all three are Good and at least 75% of its visits are Good. Hover a country to see its visits, the value of each metric, the change from the earlier period and the visits affected.

## Before the first data [#before-the-first-data]

If the RUM script never sent data, each RUM Monitoring page shows an example of the page. On the Overview, the title is "Install the RUM script to see how fast your site is for real visitors". Owners and admins click **Install the script** to open the install steps. Members see "Not connected – ask an owner or admin". See [Install the RUM script](/connect/rum-script).

The script on your site can have the tracking ID of another domain. Then the page says: "A script is on your site, but it carries a different tracking ID. Replace it with the snippet for this domain."

If VitalSentinel finds the script but no visit came yet, the page shows **Waiting for the first data**: "The script is on your page. Numbers appear within minutes of a visit." The sidebar shows "Script found – waiting for the first visit".

## Troubleshooting [#troubleshooting]

### Why does RUM Monitoring show no data? [#why-does-rum-monitoring-show-no-data]

If the page shows **Install the script**, the RUM script never sent data. Install it with the steps in [Install the RUM script](/connect/rum-script). If the page says "Script found – waiting for the first visit", open your site in a browser and wait a few minutes.

### Why does the Overview say "No Core Web Vitals data for this period"? [#why-does-the-overview-say-no-core-web-vitals-data-for-this-period]

There were no visits on the selected device in these dates and filters. Select **Desktop** or **Phone** in the dock, select a longer date range, or remove a filter.

### Why does RUM Monitoring say "No new data from" my domain? [#why-does-rum-monitoring-say-no-new-data-from-my-domain]

RUM Monitoring received no new data for some time. The banner shows the date of the **Last data**. The script may have been removed in a deploy, or the site had no visitors. Check that the script is still on your pages, then click **Check the script**. If the script is gone, click **Reinstall the script**. Your history is kept.

### Why does RUM Monitoring say it "has reached this month’s limit"? [#why-does-rum-monitoring-say-it-has-reached-this-months-limit]

Your workspace used all RUM page views of your plan for this billing cycle. RUM Monitoring keeps the data it already has, but it stores no new data until the limit resets. To get more page views, change your plan in [Billing](/workspace/billing).

### Why do my numbers differ from Google's numbers? [#why-do-my-numbers-differ-from-googles-numbers]

Google measures Chrome visits only, over the last 28 days. RUM Monitoring measures all visitors in the dates and filters that you select. So the two can differ. Each metric page shows both in the **Google and your own visitors** card.

### Why is a value gray, without a rating? [#why-is-a-value-gray-without-a-rating]

Fewer than 30 visits measured it in the selected dates and filters. A rating from so few visits is not reliable. Select a longer date range or remove a filter.

## Related [#related]

- [Install the RUM script](/connect/rum-script) - add the script that RUM Monitoring needs
- [Metrics and thresholds](/help/metrics-and-thresholds) - the Good and Poor limits of every metric
- [CrUX Monitoring](/crux-monitoring/overview) - Google's own Core Web Vitals for your site
- [Synthetic Monitoring](/synthetic-monitoring/overview) - lab tests of your pages on a schedule
- [Performance & Reliability](/web-analytics/performance-and-reliability) - if slow pages cost you visitors
- [Using the app](/getting-started/using-the-app) - the filter dock, compare and page tours