Synthetic vs. RUM

Synthetic monitoring and Real User Monitoring answer different questions about the same system.

Synthetic monitoring asks: "Is the application working right now?" It sends scripted probes from controlled locations on predictable schedules. The probes don't care if it's 3 AM or if traffic is zero—they run anyway, testing exactly what you told them to test.

RUM asks: "How are real users actually experiencing this?" It instruments user sessions and reports back what happened. The diversity is staggering—every device, every network, every browser version, every geographic location where you have users.

The fundamental difference: synthetic monitoring catches the 3 AM outage. RUM tells you that nobody cared because your users are asleep.

Proactive vs. Reactive

Synthetic monitoring detects problems before users do. Your checkout flow broke at 2 AM? Synthetic tests caught it immediately. By the time morning traffic arrives, you've already fixed it.

RUM detects problems synthetic tests miss. Real users access applications in ways you didn't anticipate when writing test scripts. They use features you forgot existed. They browse from locations you didn't think to monitor. They encounter edge cases that never occurred to you.

This isn't a flaw in either approach—it's why you need both. Synthetic tests encode your assumptions about how users behave. RUM reveals how users actually behave. The gap between assumption and reality is where the interesting problems live.

Consistency vs. Reality

Synthetic tests produce comparable data. The same script, same location, same time of day—run it today and next week and the results mean something relative to each other. This consistency makes trend analysis possible. If synthetic tests slow down after a deployment, that deployment caused it.

RUM data is messy because reality is messy. Tuesday's average load time can't be directly compared to Wednesday's because the user mix changed. Maybe more mobile users showed up. Maybe a viral post drove traffic from a different region. Statistical significance requires thinking about distributions, percentiles, and population shifts.

But that messiness IS the signal. Synthetic monitoring tells you how the application performs under controlled conditions. RUM tells you how it performs under actual conditions. Controlled conditions are useful for debugging. Actual conditions are what your users experience.

Geographic Truth

Synthetic monitoring lets you test from anywhere you choose. Thinking about launching in Singapore? Run synthetic tests from Singapore before you have a single user there. Want to verify performance from six continents? Configure monitors on six continents.

RUM shows you where your users actually are. If 80% of your traffic comes from North America, 80% of your RUM data comes from North America. You can't will more Asian data into existence—you need Asian users.

This creates different blind spots. Synthetic monitoring might obsess over locations with few real users. RUM might completely ignore regions you're planning to expand into. Neither is wrong; they're answering different questions.

What Gets Tested

Synthetic monitoring covers what you script. Your critical checkout flow? Tested every minute. That obscure settings page nobody visits? Probably not scripted. This prioritization makes sense—you test what matters most. But it creates blind spots.

RUM covers everything users touch. Even that settings page gets monitored if anyone visits it. RUM reveals feature usage patterns you didn't expect, including features you built two years ago and forgot about.

New features show this contrast clearly. Synthetic tests must be explicitly written for new features. RUM automatically captures performance data the moment the first user accesses a feature—though you won't know to look at that data until you specifically query for it.

Cost Shapes Strategy

Synthetic monitoring costs scale with configuration. More tests, more locations, more frequency—more cost. A startup and enterprise can pay similar amounts if they configure similar monitoring. Costs are predictable.

RUM costs scale with traffic. More users, more sessions, more data—more cost. Growing your user base grows your monitoring bill proportionally. Sampling can control costs, but sampling means accepting that you might miss problems affecting small user segments.

This shapes strategy differently. Synthetic cost optimization means reducing test frequency or cutting locations. RUM cost optimization means sampling—accepting less data for lower cost. Neither is free; both involve tradeoffs.

Alerting Differently

Synthetic alerting is straightforward. If the test fails, alert. If response time exceeds threshold, alert. The consistency of synthetic data makes thresholds meaningful.

RUM alerting requires sophistication. Natural variation is high. Absolute thresholds generate noise because some percentage of users will always have slow experiences due to bad networks or old devices. Percentage-based thresholds work better: alert if more than X% of page loads exceed Y seconds. Anomaly detection helps identify unusual patterns in inherently noisy data.

Timing differs too. Synthetic alerts fire immediately when a test fails. RUM alerts require aggregating data across multiple users before statistical confidence is reached—a slight delay, but one that filters out single-user flukes.

The Complementary Workflow

In practice, you use both:

1. Synthetic monitoring detects a response time increase
2. You check RUM to see if real users are affected (sometimes synthetic anomalies don't impact users)
3. RUM segmentation reveals the problem mainly affects mobile users
4. You write new synthetic tests targeting mobile to reproduce the issue consistently
5. After fixing, synthetic tests verify the fix
6. RUM confirms real users experience improved performance

Synthetic provides the early warning and the reproducible test case. RUM provides the reality check and the confirmation.