The uptime dashboard is green for the whole month. Support has nine tickets from the same week saying the checkout button does nothing.<\/p>\n\n\n\n
Both are accurate. The probe hits the homepage every minute from a datacenter, gets a 200 back, and moves on. It never logs in, never adds anything to a cart, and never runs the third-party payment script that is throwing a JavaScript error on one browser version. The check was answering a question nobody was asking.<\/p>\n\n\n\n
That gap is what the synthetic vs real user monitoring argument is actually about. It isn’t a tooling preference or a budget line. It’s about which failures each approach is structurally incapable of seeing, and what happens when you only run one of them.<\/p>\n\n\n\n
This post covers what each method really measures, the blind spot in each that bites hardest, how to choose when you can only afford one, and how to wire both together so they explain each other instead of arguing.<\/p>\n\n\n\n
Start with the one that catches people out, because it is invisible until the worst possible moment.<\/p>\n\n\n\n
Real user monitoring is passive. A script in the page collects timings and errors from actual visitors and beacons them back. No visitors, no data. So when your site is genuinely, completely down, the browser never loads, the RUM script never executes, and your error rate goes to zero.<\/p>\n\n\n\n
Zero errors. A flat, quiet, beautiful dashboard. During an outage.<\/p>\n\n\n\n
I’ve seen teams build alert rules on RUM error counts and then wonder why nothing fired. A threshold alert on “errors above X” cannot fire on a metric that has stopped reporting. If you alert on RUM at all, you need a companion rule on the absence of data, and that rule needs a sensible window, because low-traffic sites go quiet at 3am for entirely normal reasons.<\/p>\n\n\n\n
The mirror-image problem on the synthetic side is quieter but just as expensive. A scheduled probe only ever tests what you told it to test. Every path you didn’t script is unmonitored, and it looks exactly the same on the dashboard as a path you did script and that’s working. Coverage gaps and healthy systems are visually identical.<\/p>\n\n\n\n
So: synthetic monitoring is blind to what you forgot to check. RUM is blind when nobody is looking. Neither of those is a small caveat.<\/p>\n\n\n\n
A synthetic check is an active request on a schedule, from infrastructure you don’t own, against an endpoint you do. It ranges from a plain HTTP GET up to a full scripted browser session that logs in and walks a purchase flow.<\/p>\n\n\n\n
The simplest useful version is something you can run by hand right now. This asks curl to throw away the body and print only the timing breakdown, which tells you where<\/em> the time went rather than just how much of it there was:<\/p>\n\n\n\n Each value is cumulative from the start of the request, so you subtract to get the phase. A slow If you’re already running Prometheus, the self-hosted version of this is the blackbox exporter. It probes endpoints from outside and exposes the result as metrics. The config below is the whole trick: Prometheus doesn’t scrape the target, it scrapes the exporter and passes the target as a URL parameter.<\/p>\n\n\n\n Those three relabel rules have to run in that order: copy the target into the query parameter, keep the original URL as the The metrics you’ll actually alert on:<\/p>\n\n\n\n The certificate one is worth setting up even if you do nothing else. It’s the single highest-value synthetic check most small teams are missing, and it catches a failure mode that takes an entire site offline with no warning and no gradual degradation to notice first.<\/p>\n\n\n\n RUM is a small JavaScript agent that reads the browser’s own performance APIs and ships the results somewhere. Google’s Three things are worth understanding about that snippet. The callbacks fire when the metric is final<\/em>, not on a timer, which is why Interaction to Next Paint can only be reported near the end of a session. If you’d rather not build the collection side, the managed options split roughly into full-stack platforms (Datadog RUM, New Relic, Dynatrace), error-tracking tools that grew into RUM (Sentry), and open-source agents you can point at your own backend. Grafana Faro is the notable one in that last group: a browser SDK that ships web vitals, errors and traces to a collector you run yourself or to Grafana Cloud, which means your frontend signals land next to your Prometheus metrics and Loki logs instead of in a separate tab.<\/p>\n\n\n\n Strip away the vendor framing and the division is clean. Synthetic answers “is the thing I defined still working?”<\/em> RUM answers “what are people actually experiencing right now?”<\/em><\/p>\n\n\n\n Which means they belong to different jobs. Synthetic owns availability, contractual uptime, certificate and DNS health, and regression gates in CI. RUM owns experience, Core Web Vitals, conversion-adjacent performance work, and prioritisation. If you find yourself arguing about which is “better”, you’re comparing a smoke detector to a customer satisfaction survey.<\/p>\n\n\n\n Synthetic tells you something broke. RUM tells you whether it mattered, and to whom.<\/p>\n<\/blockquote>\n\n\n\n Most teams can’t stand up both properly in the same quarter. Here’s the order I’d work in.<\/p>\n\n\n\n One thing worth checking before you buy anything: what your hosting already gives you. Managed WordPress plans and VPS providers like InterServer often include basic availability alerting and a status page, and Cloudflare exposes edge-side request and error data for anything behind it. That may be enough of the availability layer that you can spend the budget on the experience layer instead.<\/p>\n\n\n\n The payoff for running both isn’t two dashboards. It’s that each one narrows the search when the other fires.<\/p>\n\n\n\n Uptime monitoring is the simplest form of synthetic monitoring: a scheduled request checking for a successful response. Full synthetic monitoring extends that to multi-step browser journeys, API sequences, DNS, TCP and traceroute checks. Same category, different depth.<\/p>\n\n\n\n No, and this is the most expensive misunderstanding in the whole synthetic vs real user monitoring discussion. RUM depends on pages loading. When the site is down, the RUM stream goes quiet rather than red, so an outage looks identical to a slow night unless you have explicitly alerted on the absence of data.<\/p>\n\n\n\n Work backwards from how fast you need to detect a problem, then account for the consecutive failures you require before alerting. A one-minute interval with a three-failure threshold means roughly three minutes to detection. Cheap HTTP checks can run frequently; browser journeys usually run every five to fifteen minutes because they cost far more per execution.<\/p>\n\n\n\n Slightly, and it’s a real trade-off rather than a rounding error. A minimal web vitals collector adds very little; a full session-replay agent is a much heavier thing to load. Load the agent asynchronously, sample sessions rather than capturing every one, and measure the agent’s own cost before you decide it’s free.<\/p>\n\n\n\n They’re measuring different things from different places. A synthetic HTTP probe checks that a response came back; PageSpeed Insights reports both a throttled lab simulation and field data from real Chrome users. Neither is wrong. If the field section fails, real users on slower devices are having a worse time than your probe is.<\/p>\n\n\n\n Usually not. A low-traffic site gets almost nothing out of RUM because there aren’t enough sessions to make a percentile meaningful. Run solid external uptime and certificate checks, look at Search Console’s Core Web Vitals report for whatever field data exists, and add RUM when traffic justifies it.<\/p>\n\n\n\n Yes. Blackbox exporter plus Prometheus and Alertmanager covers synthetic; Grafana Faro with a collector you run covers RUM. The catch is that self-hosted probes lose the one property that makes external monitoring valuable, which is independence. Run at least one check from a network you don’t control, even if everything else is yours.<\/p>\n\n\n\n Synthetic vs real user monitoring isn’t a choice between two products that do the same job. It’s a choice about which blind spot you’re willing to live with, and the answer to that changes as your traffic changes.<\/p>\n\n\n\n If you take one thing away: a quiet dashboard is not evidence of health. Synthetic monitoring goes quiet when you never wrote the check. RUM goes quiet when the site is down. Both silences look exactly like everything being fine, and both need an explicit alert on missing data before you can trust the green.<\/p>\n\n\n\n This is a good chunk of what I do. If your uptime page says one thing and your users say another, I can help with:<\/p>\n\n\n\n Send me a screenshot of your current alert rules, a scrape config, or just the endpoint that keeps going green while people complain, and I’ll tell you what it’s missing.<\/p>\n\n\n\ncurl -o \/dev\/null -s -w \n 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}n' \n https:\/\/example.com\/<\/code><\/pre>\n\n\n\ntime_namelookup<\/code> is DNS. A gap between time_connect<\/code> and time_appconnect<\/code> is the TLS handshake. A gap between time_appconnect<\/code> and time_starttransfer<\/code> is your application thinking. That last one is the number that actually correlates with user-visible slowness on a server-rendered page.<\/p>\n\n\n\nscrape_configs:\n - job_name: blackbox-http\n metrics_path: \/probe\n params:\n module: [http_2xx]\n static_configs:\n - targets:\n - https:\/\/example.com\/\n - https:\/\/example.com\/checkout\n relabel_configs:\n - source_labels: [__address__]\n target_label: __param_target\n - source_labels: [__param_target]\n target_label: instance\n - target_label: __address__\n replacement: 127.0.0.1:9115<\/code><\/pre>\n\n\n\ninstance<\/code> label so your graphs are readable, then overwrite the scrape address with the exporter. Get the order wrong and Prometheus scrapes the exporter’s own metrics endpoint, you get no probe_*<\/code> series at all, and everything looks fine because there’s nothing red to see.<\/p>\n\n\n\ngroups:\n - name: blackbox\n rules:\n - alert: EndpointDown\n expr: probe_success == 0\n for: 3m\n labels:\n severity: critical\n - alert: CertExpiringSoon\n expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 21\n for: 1h\n labels:\n severity: warning<\/code><\/pre>\n\n\n\nWhere synthetic monitoring wins<\/h3>\n\n\n\n
\n
Where synthetic monitoring falls down<\/h3>\n\n\n\n
\n
Real user monitoring: what the browser actually reports<\/h2>\n\n\n\n
web-vitals<\/code> library is the reference implementation for the metrics that matter, and it’s deliberately tiny:<\/p>\n\n\n\nimport { onCLS, onINP, onLCP } from 'web-vitals';\n\nfunction send(metric) {\n navigator.sendBeacon('\/rum', JSON.stringify({\n name: metric.name,\n value: metric.value,\n rating: metric.rating,\n id: metric.id,\n path: location.pathname\n }));\n}\n\nonCLS(send);\nonINP(send);\nonLCP(send);<\/code><\/pre>\n\n\n\nsendBeacon<\/code> is used instead of fetch because it survives the page being closed. And metric.rating<\/code> gives you the good \/ needs-improvement \/ poor bucket without you hardcoding thresholds that Google may revise.<\/p>\n\n\n\nWhere RUM wins<\/h3>\n\n\n\n
\n
Where RUM falls down<\/h3>\n\n\n\n
\n
Synthetic vs real user monitoring: the honest split<\/h2>\n\n\n\n
\n
How I’d decide what to run first<\/h2>\n\n\n\n
\n
Mistakes that look like monitoring<\/h2>\n\n\n\n
\n
OK<\/code> without touching the database is testing your web server’s ability to serve a string. Make the check exercise a real dependency, or add a content assertion on a page that only renders correctly when the database answers.<\/li>\n\nMaking the two views agree<\/h2>\n\n\n\n
\n
avg_over_time(probe_success[30d])<\/code> is your uptime figure. p75 INP is your experience figure. Don’t let the two SLOs drift into using each other’s data.<\/li>\n\nFrequently asked questions<\/h2>\n\n\n\n
Is uptime monitoring the same thing as synthetic monitoring?<\/h3>\n\n\n\n
Can real user monitoring replace uptime checks?<\/h3>\n\n\n\n
How often should synthetic checks run?<\/h3>\n\n\n\n
Does RUM slow down the site it’s measuring?<\/h3>\n\n\n\n
Why does my synthetic check pass while PageSpeed Insights fails?<\/h3>\n\n\n\n
Do I need both if I run a small brochure site?<\/h3>\n\n\n\n
Can I self-host all of this?<\/h3>\n\n\n\n
\n\n\n\nThe one thing worth remembering<\/h2>\n\n\n\n
Need help getting your monitoring to match reality?<\/h2>\n\n\n\n
\n