Your server is running. Logs are clean. Grafana is green. But a customer in Berlin emails support: "Your site won't load and hasn't for 20 minutes". You check — everything works for you. Because you're checking from the same datacenter as your server. The customer's DNS resolver is returning a stale IP from yesterday's migration. Or a CDN edge in Europe is serving 502s. Or Cloudflare WAF blocked their ISP's subnet.
Synthetic monitoring solves exactly this problem: it checks your service from the outside, from the same locations where real users connect. Regularly, automatically, 24/7 — including 3 AM on Sunday when your site has zero traffic and RUM shows nothing.
Synthetic vs RUM: two approaches to monitoring
Web application monitoring splits into two fundamentally different approaches. Understanding the difference is key to choosing the right strategy.
Synthetic monitoring (active)
The monitoring system generates traffic itself. From external locations (agents), HTTP requests are sent to your site or API on a schedule — every 30 seconds, every minute, every 5 minutes. The request follows the same path as a real user's request: DNS resolution → TCP connection → TLS handshake → HTTP request → receive response.
Each check's result is recorded: status code, response time, TTFB, response size, content (if validation is configured). If something is wrong — the incident system reacts immediately.
Real User Monitoring (passive)
A JavaScript snippet in the browser collects data about real users: page load time, LCP, FID, CLS, JavaScript errors, failed fetch requests. Data is aggregated to show the real picture of user experience.
RUM provides invaluable insight into how your site works in the real world: on slow 3G in India, on an old iPhone SE, through a corporate proxy. But RUM has a fundamental limitation: no users, no data.
Synthetic monitoring answers: "Is my service working right now, from these specific locations, by these specific criteria?" The answer is yes/no, with exact timing and details.
RUM answers: "What experience are real users getting?" The answer is statistical distribution across percentiles, devices, regions, pages.
When synthetic monitoring is essential
Synthetic monitoring isn't an alternative to RUM — it's a different tool for different tasks. There are situations where only synthetic works:
Detecting outages during off-hours
B2B SaaS at 2 AM local time has near-zero traffic. If the server goes down at 2:00 and comes back at 7:00 — RUM captures nothing. Five hours of downtime, invisible to passive monitoring. A synthetic check detects the problem in 30-60 seconds, regardless of traffic.
Performance baseline
RUM data is noisy: each user on their own device, their own network, their own browser extensions. Hard to distinguish server degradation from "10 users have slow WiFi". A synthetic check makes the same request from the same location every minute — a perfect baseline. If response time jumps 200ms, the problem is server-side, not client-side.
API and backend service monitoring
RUM lives in the browser. API endpoints, webhook receivers, microservice health checks — all invisible to RUM. API monitoring is entirely synthetic's domain: send a request, validate the response, measure timing.
Pre-launch and staging
By definition, a staging environment has no real users. But you need to know it works before deploying to production. Synthetic monitoring of staging is standard CI/CD practice.
SLA compliance and uptime reporting
SLA requires objective, measurable data: monthly availability, incident count, mean recovery time. RUM doesn't provide these — it doesn't know when the site "was down" because there was simply no data. Synthetic monitoring checks continuously and provides accurate uptime figures.
Types of synthetic checks
"Synthetic monitoring" is an umbrella term. It covers different types of checks, each for its own purpose.
HTTP/HTTPS check. The basic type. Sends GET or POST requests, checks status code, response time, response content. Works for sites, APIs, health endpoints. In AtomPing — the primary monitoring type.
DNS check. Verifies a domain resolves to the correct IP. Catches DNS-level problems before they become HTTP errors. DNS monitoring is a separate check type, running in parallel with HTTP.
TCP/Port check. Verifies a port is open and accepting connections. Used for databases, SMTP servers, custom TCP services. Port monitoring doesn't depend on HTTP.
SSL/TLS check. Validates certificate: expiration, chain, hostname match. TLS monitoring alerts 30 days before expiry — a critical check because expired SSL = complete failure.
ICMP/Ping check. Checks if a host responds to ICMP echo. The lowest-level type — if ping fails, the problem is network-level or the host is offline. Ping monitoring is useful for servers, routers, network equipment.
Keyword check. HTTP request + verify the response contains (or doesn't contain) specific text. Catches "200 OK but it's an error page inside". Keyword monitoring protects against silent failures.
Heartbeat check. Inverted synthetic: not the monitoring system checking your service, but your cron job pinging the monitoring system. If the ping doesn't arrive on time — alert. A dead man's switch for scheduled tasks.
Multi-region: why check from multiple locations
Single-location checks are better than nothing, but they generate false alerts: network jitter between probe and your server, DNS cache on the probe, maintenance at the probe's hosting provider — all look like "site is down" when it's actually working.
Multi-region monitoring solves this fundamentally. Instead of one agent, 11 distributed across Europe. Each checks independently. Results are compared:
1 of 11 agents sees DOWN → local network issue, result suppressed. No alert.
8 of 11 agents see DOWN → real incident, confirmed by quorum. Alert sent immediately.
All 11 agents see DOWN → global outage. Maximum-priority incident.
Bonus: multi-region data shows real latency patterns by geography. If response time from Frankfurt is 80ms but from Helsinki is 340ms, you have a routing or CDN configuration problem in Northern Europe.
What to check: beyond "site responds"
Primitive synthetic monitoring checks: "Did the server return 200 OK?". It's not enough. The server can return 200 with empty JSON, 200 with an nginx error page, 200 with data cached from three days ago.
Advanced synthetic monitoring validates:
Status code. Not just "2xx", but the specific code. 200 for GET, 201 for POST, 204 for DELETE. If you get 301 instead of 200, someone changed the routing.
Response content. Keyword check for a key word ("Dashboard", "status":"ok") or JSON path assertion ($.data.length > 0). Catches silent failures invisible by status code alone.
Response time. Absolute thresholds (>500ms = warning, >2s = critical) and degradation relative to baseline. Response time tracking records history for trend analysis.
Headers. Content-Type, Cache-Control, CORS headers. A missing CORS header breaks the entire frontend even if the API works.
TLS validity. In parallel with HTTP checks — certificate validation. If less than 30 days until expiry — notify.
Setting up synthetic monitoring: practical checklist
Minimal configuration covering 95% of typical SaaS product needs:
1. HTTP check on homepage. URL: your domain. Interval: 1 minute. Expected code: 200. Keyword: product name or unique DOM element. Regions: 3+.
2. HTTP check on API health. URL: /api/health or /health/ready. Interval: 30 seconds. Expected code: 200. Keyword: "status":"healthy". This is your canary — first indicator of backend problems.
3. DNS check. Verify domain resolves to correct IP. Interval: 5 minutes. Catches DNS-level issues that HTTP check detects with delay.
4. SSL/TLS check. Validate certificate. Alert 30 days before expiry. 30 seconds to set up, prevents one of the costliest types of downtime.
5. Heartbeat for cron jobs. For every critical scheduled task — backups, syncs, cleanups — add a curl to the heartbeat URL at the end of the script.
6. Alerting. Slack, Telegram, email — your choice. Rule: hard incident after 2-3 consecutive checks with issues, confirmed by quorum from multiple regions. This eliminates 99% of false alerts.
Synthetic monitoring for different service types
E-commerce
Critical endpoints: homepage, catalog, cart, checkout, payment callback. At minimum, HTTP checks on each with keyword validation (verify the catalog page has products, not an empty list). Payment callback endpoint needs the most frequent checks — every 30 seconds, because its unavailability means lost transactions.
SaaS API
Health check endpoint with deep validation (DB, Redis, external dependencies). Separate checks on auth endpoint and core CRUD operations. JSON path assertions on API responses. Response time monitoring with thresholds tied to your SLO.
Marketing site / Landing pages
HTTP check + keyword validation (verify CTA buttons or key text are in place). DNS check is mandatory because marketing sites often use CDN with CNAME, and DNS record issues break all traffic. SSL check for certificates updated through CDN providers.
Microservices
Outside-in approach: start with the external gateway, then add health checks for individual services. Each service gets its own /health/ready. If the gateway is healthy but a specific service isn't, you know exactly where to look instead of sorting through 15 logs.
Common mistakes
Monitoring from only one region. Saves 5 minutes of setup, costs hours of false alerts. Three regions is the absolute minimum for quorum.
Checking only the homepage. A CDN-hosted homepage can work while the backend is dead. Monitor API endpoints, authenticated pages, critical user flows.
No content validation. Status code 200 ≠ "everything works". Add a keyword check — one line of text you expect to see in the response.
Too aggressive thresholds. Alert on every single timeout = alert fatigue within a week. Use hard incident thresholds (2-3 consecutive failures) and quorum confirmation.
Forgetting SSL monitoring. Certificate expires — instead of one alert 30 days ahead, you get a complete outage on the weekend. SSL monitoring is 30 seconds to set up and saves you from weekend incidents.
FAQ
What is synthetic monitoring?
Synthetic monitoring uses scripted transactions to simulate user interactions with your website or API from external locations. Unlike real user monitoring (RUM), which passively collects data from actual visitors, synthetic monitoring actively sends requests at regular intervals — even when no real users are online. This makes it ideal for catching outages at 3 AM or during low-traffic periods.
What is the difference between synthetic monitoring and real user monitoring?
Synthetic monitoring proactively tests your site using scripted checks from known locations on a fixed schedule. RUM passively collects performance data from real browsers as actual users interact with your site. Synthetic gives you consistent baselines and instant outage detection. RUM gives you real-world user experience data with all the variability of different devices, networks, and locations.
Do I need both synthetic and real user monitoring?
For most teams, synthetic monitoring covers 90% of monitoring needs — especially if you're a B2B SaaS or API-driven product. RUM adds value when you have high consumer traffic with diverse devices and need to understand real user experience. Start with synthetic, add RUM when you have the traffic volume to make it statistically meaningful.
How often should synthetic checks run?
Critical endpoints (login, payment, API health): every 30-60 seconds. Important pages (dashboard, product listings): every 1-3 minutes. Secondary pages (blog, docs, about): every 5-10 minutes. Match frequency to business impact — if a 2-minute outage costs you thousands, check every 30 seconds.
Can synthetic monitoring test APIs and not just websites?
Yes. In fact, API monitoring is one of the strongest use cases for synthetic monitoring. You can validate status codes, check response body content with JSON path assertions, verify headers, measure latency, and test authenticated endpoints — all on a fixed schedule from multiple regions.
Does synthetic monitoring affect my server performance?
Negligibly. A synthetic check is a single HTTP request every 30-60 seconds — far less than one real user browsing your site. Even with 10 monitoring regions checking every 30 seconds, that's 20 requests per minute. For comparison, a single user loading a modern SPA generates 30-50 requests in a page load.