The two measurement strategies
Every website performance measurement falls into one of two buckets:
Synthetic monitoring runs scripted checks against your site from infrastructure you don’t own. A server somewhere — an “agent” or “probe” — pretends to be a user, makes requests, and records what happens. Uptime monitors are the simplest form of synthetic monitoring. Headless browser checks that walk through your checkout flow are a richer form.
Real-user monitoring (RUM) instruments your actual users’ browsers and reports back what they experienced. You drop a JavaScript snippet on your pages, and every visitor’s session generates telemetry — page load times, JavaScript errors, geographic location, browser version, conversion funnel events.
Both are useful. They answer different questions. Confusing them is one of the most common mistakes I see when teams set up observability.
What synthetic is good at
Synthetic monitoring is your before-the-customer signal. The whole point is that the check happens on infrastructure you control, on a schedule you set, regardless of whether real traffic is hitting the site.
The questions it answers well:
- Is the site up? A check from a known-good probe either succeeds or fails. The answer is unambiguous.
- Is it up from outside? If your synthetic probes live in five different regions and they all succeed, you know the site is globally reachable. If one region fails, you’ve localized the problem.
- Is the SSL cert valid? The DNS resolving? The TLS handshake completing? Synthetic checks exercise the full stack on every request.
- Is the checkout flow still working? A scripted browser check that completes a fake purchase will tell you the day someone breaks the cart, even if no real users are testing it at that moment.
The strength is predictability. The check happens every minute whether or not anyone is using your site. You get a clean, time-series signal that’s easy to alert on.
The weakness is representation. The probe isn’t a real user. It runs from a data center, on a clean network, on a known browser, hitting cached resources at predictable times. It tells you the site can be reached. It doesn’t tell you what reaching it feels like to your customers.
What RUM is good at
Real-user monitoring is your what’s-actually-happening signal. Once you instrument your pages, every visitor’s experience becomes data — and that data captures all the variables synthetic can’t simulate.
The questions it answers well:
- What’s the median page load time for users on mobile networks in Brazil? RUM has the actual numbers from actual sessions, broken down by every dimension you can sample.
- Which browser version is breaking? A JavaScript error tracked across thousands of sessions shows you the spike when Chrome 132 ships with a bug.
- Is the homepage slow today? RUM reports the distribution — the 50th, 75th, 95th percentile — across real traffic, not a single number from one probe.
- Did the new deploy hurt conversion? If you tag RUM events with deploy IDs, you can see whether checkout completion rate dropped after release.
The strength is realism. Every measurement is what a real user actually experienced, including all the variables that synthetic can’t replicate — flaky cellular networks, ad blockers, third-party scripts, geographic latency, device CPU.
The weakness is dependence on traffic. RUM only generates data when users visit. If your site has 100 visits a day, you don’t have enough samples to detect a 2x slowdown in the 95th percentile of mobile users in a specific region. The signal is noisy at low traffic, and absent when traffic is zero — exactly the moment you most want to know whether the site works.
It also can’t tell you anything when the site is down. A user who fails to load the page never runs your RUM script, so the failure is invisible from inside RUM. This is the most important point on this page.
The division of labor
A reasonable production observability stack uses both, like this:
Synthetic monitoring covers:
- Uptime / availability
- SSL certificate expiry
- DNS resolution
- API endpoint health
- Critical user journeys (login, checkout, signup)
- Multi-region availability
RUM covers:
- Real-world page load distributions
- Geographic and device-specific performance
- JavaScript error tracking
- Conversion and funnel analytics
- Third-party script impact
Neither replaces the other. Synthetic catches the outages and the regressions in the critical paths. RUM catches the silent degradations that only affect real users on real networks.
A common failure mode
The mistake I see most often is teams who install RUM, see dashboards full of real data, and skip synthetic. The logic is “we have monitoring now.” Then a deploy breaks the homepage 500 error response, traffic dies, and RUM goes silent because no one is loading pages anymore. The team’s dashboards show “no traffic, no errors” — which looks healthy at a glance — until a customer emails three hours later.
Synthetic is what surfaces the absence of traffic as a problem. RUM by itself can’t.
The inverse mistake is also common: teams who have synthetic monitoring, see green dashboards, and conclude the site is fine — while real users on bad networks are getting 8-second load times. Synthetic from a clean data center can be perfectly green while RUM tells you the customer experience is broken.
What about headless browser checks?
Headless browser-based synthetic monitoring (Playwright, Puppeteer-driven probes) sits between basic synthetic and RUM. It runs a real browser, executes your JavaScript, takes screenshots, and measures things like time-to-interactive — but it’s still running from infrastructure you control, on a schedule.
Useful for:
- Testing flows that require login, JavaScript-heavy interactions, or third-party widgets
- Detecting visual regressions
- Measuring perceived performance (FCP, LCP, CLS) under controlled conditions
The cost is real — headless browser checks are 10–100x more expensive to run than simple HTTP checks. Reserve them for critical flows and run them less often (every 5–15 minutes) than your basic uptime checks (every 30–60 seconds).
Practical setup recommendations
If you’re starting from zero:
- Set up basic HTTP uptime checks on the URLs that matter — homepage, login, key API endpoints. Every 30–60 seconds, from at least two regions. This is the cheapest, most important layer.
- Add SSL certificate monitoring for every domain. Free, prevents one of the most common outage causes.
- Add RUM if your traffic is high enough to make the data meaningful (rule of thumb: 1,000+ daily visits). For lower traffic, RUM data is too sparse to act on.
- Add headless browser checks for critical flows once you have basic uptime in place. Don’t try to script everything — pick the 2–3 user journeys that, if broken, would be a revenue event.
- Add APM (application performance monitoring) if you need backend instrumentation — query times, internal service latency, error rates per endpoint.
The order matters because each layer compounds the value of the ones below it. Uptime monitoring without RUM is useful. RUM without uptime monitoring has blind spots. Headless checks without basic synthetic are overkill.
What MyUptimeBot does, plainly
MyUptimeBot is on the synthetic side of this picture — HTTP-based uptime checks with SSL monitoring, multi-region rechecking, and content-change detection. We’re the first layer in the stack: cheap, reliable, fast to alert, designed to catch the outages that take everything else offline.
For RUM, we don’t compete with the dedicated tools — Sentry, LogRocket, Datadog RUM, or open-source alternatives. Different jobs.
The right answer for most teams is: synthetic from us (or a similar service) covering availability, plus a RUM tool of your choice covering real-user experience. Two layers, two signals, each filling in the other’s blind spots.
