Synthetic Monitoring Explained: Proactive vs Reactive Monitoring
Reactive monitoring tells you when something broke. Synthetic monitoring tells you something is about to break — before your users find out. Here's the difference, and why you probably need both.
What is synthetic monitoring?
Synthetic monitoring (sometimes called active monitoring) works by simulating user interactions with your application on a scheduled basis — independent of whether real users are active. The "synthetic" part means the traffic is artificial, generated by monitoring infrastructure rather than real users.
In practice, synthetic monitoring can be as simple as an HTTP check that hits your homepage every minute, or as complex as a scripted browser flow that simulates a full signup, payment, and onboarding sequence.
The key insight: synthetic monitoring runs continuously. It doesn't wait for a user to hit an error — it proactively looks for problems on your behalf.
Reactive monitoring: what it is and where it falls short
Reactive monitoring catches problems after they happen. The most common forms are:
- Error logging: Sentry, Datadog Logs, CloudWatch — captures errors when real users trigger them
- Application metrics: Tracks request rates, error rates, and latency from real traffic
- User-reported issues: Support tickets, social media, Slack messages from users
Reactive monitoring is valuable — you need error logs. But it has a fundamental limitation: it requires users to experience the problem first.
At 3am on a Sunday when traffic is low, a broken checkout flow might go undetected for hours because no real users are attempting purchases. Your error logs stay quiet. Your metrics look fine. But your revenue is at zero because nobody can complete a payment.
Where synthetic monitoring fills the gap
Synthetic monitoring is the answer to: "What if nobody is hitting the broken thing right now?"
It's particularly valuable for:
Low-traffic windows
Off-peak hours, nights, weekends. Real user traffic is sparse, so reactive monitoring has few signals to work with. Synthetic checks run on schedule regardless.
Critical user flows
Signup, login, checkout, password reset. These paths may not see constant traffic, but when they break, the impact is immediate and severe. Synthetic flows catch regressions before users do.
Third-party dependencies
Payment processors, auth providers, email services. These external services can degrade without your infrastructure producing any errors. A synthetic check that tests the full flow catches degradation at the boundary.
Performance baselines
Consistent synthetic load lets you track response time trends over time, independent of traffic patterns. You'll see a 200ms regression that would be invisible in noisy real-user data.
Types of synthetic monitoring
Not all synthetic monitoring is the same. The complexity and cost vary significantly:
- HTTP/uptime checks — The simplest form. Send a GET or POST request to a URL on a schedule, check for a 200 status code. Catches complete outages immediately. This is where most teams start.
- Keyword/content checks — HTTP check plus verify that the response body contains expected content. Catches cases where a page returns 200 but serves a cached error page or stale content.
- API transaction checks — Scripted sequences of HTTP requests that simulate multi-step API flows: authenticate, fetch resource, create record, verify result. Catches integration regressions that simple uptime checks miss.
- Browser/end-to-end checks — Full headless browser automation (Playwright, Puppeteer) that clicks through real UI flows. Highest fidelity, highest cost. Best reserved for the most critical and complex paths.
Most SaaS teams get 80% of the value from HTTP checks and keyword checks — they're fast, cheap, and cover the most common failure modes. Browser checks are powerful but add complexity you probably don't need until scale demands it.
Proactive vs reactive: which do you need?
You need both, and they serve different purposes in your observability stack.
| Synthetic (proactive) | Reactive |
|---|---|
| Runs on schedule, no users needed | Requires real user traffic |
| Catches outages before users do | Confirms real user impact |
| Best for availability and critical flows | Best for root cause and error context |
| Works 24/7 regardless of traffic | Blind during low-traffic windows |
The practical starting point for most SaaS teams: set up synthetic HTTP checks on your most critical endpoints and add reactive error tracking (Sentry or equivalent). That combination covers the vast majority of incidents you'll face.
Add browser-level synthetic flows only when you've got the simpler layers working reliably and have identified specific flows where regressions are too costly to catch reactively.