Synthetic monitoring tests your website or API with scripted requests on a schedule, whether or not anyone is visiting. Real user monitoring (RUM) measures what actual visitors experience, from a script in their browsers, but only when they visit. Synthetic checks tell you that something is broken, often before customers notice. RUM tells you how fast and smooth the site is for the people who use it, on their devices and networks. Start with synthetic checks for availability, and add RUM when performance for real visitors becomes a question you need answered.
How synthetic monitoring works
A monitoring service plays the visitor. From a known location, on a fixed schedule, it sends a request or runs a script and judges the result. Because it does the same thing every time, results are comparable from one check to the next, and a failure at 03:00 is found at 03:00, with no traffic needed. Synthetic monitoring comes in several forms:
- Uptime checks: one request to a URL, host or port, checked for the status code, the response time and often the content. This is the simplest kind; see what uptime monitoring is.
- API checks: a request with a method, headers and body, and checks on the JSON that comes back.
- Multi-step flows: a journey such as logging in or checking out, run step by step, as plain HTTP requests or in a real browser that runs JavaScript.
- Lab performance tests: a tool such as Lighthouse loads a page on a simulated device and network and scores it.
How real user monitoring works
Real user monitoring adds a script to your pages. In each visitor’s browser it reads timings that browsers expose through standard APIs, such as Navigation Timing, and sends them to a collector. Aggregated across visits, you get distributions: how long pages take to load, how quickly they respond to clicks, which pages throw JavaScript errors, broken down by country, device and browser.
Because the results are distributions, RUM reports percentiles rather than single numbers. Google’s Core Web Vitals are measured at the 75th percentile of page loads, with these thresholds for a good experience:
- Largest Contentful Paint (loading): 2.5 seconds or less.
- Interaction to Next Paint (responsiveness): 200 milliseconds or less.
- Cumulative Layout Shift (visual stability): 0.1 or less.
There is also RUM data you don’t collect yourself. Google’s Chrome UX Report (CrUX) publishes field data from Chrome users who allow it, per page and per site, once there is enough traffic. It is the data Google uses for Core Web Vitals in search.
Side by side
| Synthetic monitoring | Real user monitoring | |
|---|---|---|
| Who generates the data | A monitoring service, on a schedule | Your visitors, when they visit |
| Needs traffic | No | Yes |
| Needs a script in your pages | No | Yes |
| Detects an outage | Yes, at the next check | Indirectly, when data stops |
| Covers | The pages and journeys you script | Every page people visit |
| Devices and networks | A few known ones | All of your visitors’ |
| Results | Pass or fail, a timing per check | Distributions and percentiles |
| Best for | Availability, alerts, catching regressions after deploys | Real performance, Core Web Vitals, errors in the browser |
What each one misses
Synthetic blind spots
- Paths you didn’t script. If the checkout flow tests one product, a broken page for another category goes unnoticed.
- Where your visitors are. A check from one city sees that city’s route to your server, not a visitor’s on a mobile network on another continent.
- Real devices. A slow phone, a browser extension or an old browser version can break or slow a page that passes every check.
RUM blind spots
- No visitors, no data. At night, on a new page or on a low-traffic site, RUM has little or nothing to say.
- Outages. When the site is down, the script never loads, so nothing is reported. A gap in a chart is easy to miss and doesn’t wake anyone.
- Visitors you can’t measure. Ad blockers and consent choices can stop the script, so the data describes the visitors who allow it.
- Weight. The script itself is extra work for the page. Load it asynchronously and check its size.
Lab data vs field data
The same split shows up in performance tools, where it is called lab and field data. A Lighthouse score is lab data: one synthetic page load on a simulated mid-range phone and network. CrUX and your own RUM are field data: what real visits measured. They often disagree. A page can score poorly in the lab and still pass Core Web Vitals in the field because most visitors have fast devices, or the other way around. Use lab data to find and fix problems and to compare one release with the next, and field data to judge what visitors actually get. The tips for a faster loading website help with both, and what a good response time is covers the server side.
Which one to start with
- Every site: synthetic uptime checks on the homepage and the pages that earn money. An outage costs more than a slow page, and only synthetic checks alert you to it reliably. The checklist of what to monitor lists the URLs worth covering.
- Shops and SaaS products: add multi-step flows for checkout or login, so a broken journey is caught even when every single page answers 200.
- Sites where search traffic matters: watch Core Web Vitals from CrUX and a daily lab test, so a slow release is spotted before it shows in rankings.
- Large or global audiences, complex front ends: add RUM to see performance and JavaScript errors per country, device and page.
How they work together
Picture a shop that deploys a new checkout on Tuesday afternoon. At 03:12 on Wednesday, the payment step starts timing out. Nobody is shopping, so RUM shows nothing unusual, but the synthetic checkout flow fails, a second check confirms it, and the on-call developer gets an alert. Fixed by 03:30. On Thursday, RUM shows that Interaction to Next Paint on the new checkout has doubled for Android visitors, which no synthetic check from a fast server would have noticed. One tool caught the outage, the other the slow experience. That is the usual division of work.
What Uptimecheck covers, and what it doesn’t
Uptimecheck is a synthetic monitoring service. It doesn’t add a RUM script to your pages, so for your own visitors’ timings and JavaScript errors, use a dedicated RUM tool next to it. What it does:
- Uptime monitoring: HTTP(S), ping and port checks as often as every minute from Stockholm, Sweden, with keyword, JSON and header checks, and each failure confirmed by a second check before an alert. Response times are split into DNS, connect, TLS, server and download.
- Flow monitoring: up to 10 steps such as opening a page, logging in, submitting a form or calling an API, with values carried from one step to the next. Plain-request flows can run every minute; flows in a real browser run JavaScript and clicks at most every 15 minutes, with a screenshot of the step that failed.
- Page speed monitoring: a daily Lighthouse test on mobile and desktop for the start page and up to 4 more pages, and, for pages and sites with enough visits, what real Chrome users experienced over 28 days from the Chrome UX Report. You get an alert when a page’s score drops below your limit.
To set up a journey, see how to monitor a login or checkout with a flow and how to check page speed. Plans start at €9 a month billed yearly or €12 billed monthly, excl. VAT; see the pricing page.
Know it’s broken before your visitors tell you. Try Uptimecheck free for 14 days, no credit card required.