Do I need both synthetic and real user monitoring?

High-traffic sites benefit from both: synthetic guards critical paths around the clock, RUM reveals real-world experience. Lower-traffic sites are usually well served by synthetic plus uptime and SSL monitoring alone.

Can RUM detect an outage?

Poorly. RUM depends on the page loading and its script running. A full outage, an expired certificate, or a DNS failure means no users load the page, so no RUM data arrives. Synthetic or availability monitoring catches those.

Which is easier to set up for client sites?

Synthetic and availability monitoring, because they need no code on the site, you point them at a URL. RUM requires embedding a script and handling visitor consent, which adds friction across many client domains.

Synthetic vs Real User Monitoring (RUM): Which Does an Agency Need

VigilDog Team · August 29, 2026 · 6 min read

If you run websites for clients, someone will eventually ask why a page felt slow, or why nobody caught the outage before the client did. The two monitoring approaches that answer those questions, synthetic and real user monitoring, sound interchangeable but measure completely different things. Choosing the wrong one leaves blind spots you only discover during an incident.

What synthetic monitoring is

Synthetic monitoring runs scripted checks against a site on a fixed schedule from servers you control. A robot loads a page (or walks through a login and checkout flow) every minute or two from a known location, and records whether it succeeded and how long it took. Because the test is identical every time, the results are clean and comparable, the same click path, the same network, the same measurement every run.

Its great strength is that it works with zero traffic. You can monitor a site at 3 a.m. when no human is on it, catch an SSL certificate that just expired, or verify a checkout still works before a single customer hits it. That makes synthetic the natural fit for uptime, availability, and critical-path assurance. The trade-off: you only ever see what your scripts test, from where you test it.

What real user monitoring (RUM) is

Real user monitoring flips the perspective. A small snippet of JavaScript on the page reports back what actual visitors experienced, their real load times, their devices, their browsers, their networks, from wherever in the world they happen to be. Instead of one synthetic robot, you get the full messy distribution of everyone who visited.

RUM surfaces things synthetic checks physically cannot: that mobile users on a specific carrier see double the load time, that a third-party script only tanks performance for returning visitors, that Core Web Vitals are fine at the median but terrible at the 95th percentile. It is the ground truth of user experience. Its weakness is the mirror image of synthetic's strength, no traffic means no data, and RUM tells you a page was slow only after real people already suffered it.

The trade-offs, side by side

Neither approach is 'better'they answer different questions. The honest way to choose is to know exactly where each one is blind.

Coverage: synthetic tests only scripted paths; RUM sees every page real users touch.
Timing: synthetic catches problems before users do; RUM catches them as users hit them.
Low traffic: synthetic works with none; RUM needs volume to be meaningful.
Consistency: synthetic gives clean, comparable trends; RUM data is noisy but real.
Setup: synthetic needs no code on the site; RUM requires a script and a privacy/consent story.
What breaks it: synthetic misses issues outside its scripts; RUM misses issues on pages nobody visited.

What an agency actually needs

For most agencies, the first and most valuable layer is not either performance approach, it is availability and integrity monitoring. Before you optimize a page's load time, you need to know the site is up, the certificate is valid, and the DNS still resolves. An expired SSL cert or a lapsed domain takes a site fully offline, and no RUM script runs on a page that will not load. That is why we draw a line between SSL monitoring vs uptime monitoring as distinct jobs.

Layer performance on top of that foundation. Use synthetic checks for the flows that must never break, homepage, login, checkout, lead forms, because they run whether or not anyone is watching. Add RUM on higher-traffic client sites where real-world experience and Core Web Vitals genuinely move business outcomes. On a brochure site with modest traffic, RUM adds noise and a consent burden for little payoff; synthetic plus solid uptime and SSL coverage is usually enough.

The practical answer for a portfolio of client sites is rarely 'pick one.' It is: make availability and certificate monitoring non-negotiable across every domain, run synthetic on the critical paths, and reserve RUM for the sites where user-experience data changes what you actually do.

Start with the layer that never lies

Whatever you decide about synthetic and RUM, the base layer, is it up, is the cert valid, is DNS intact, should be automatic and cover every client domain in one place. That is the gap VigilDog fills. Our monitoring watches SSL/TLS expiry, domain expiry, DNS and its drift, and email authentication across your whole portfolio, with white-label reports you can hand straight to clients. Add synthetic and RUM tooling on top as each site earns it, but never let the foundation be the thing a client notices first.