Synthetic monitoring is a proactive testing method that runs scripted, simulated transactions against your site, API or server on a fixed schedule — from defined locations — to catch outages and slow performance before real users hit them. Unlike monitoring that depends on live traffic, synthetic checks run whether or not anyone is actually visiting your site, which makes them the right tool for catching problems in the gaps: 3am, low-traffic regions, or a brand-new feature nobody has used yet.
The term covers everything from a simple ping every minute to a full scripted browser session that logs in, adds an item to a cart, and checks out — all without a human involved.
How synthetic monitoring actually works
A synthetic check is a script that runs on a schedule from one or more probe locations and records what happens. At its simplest, that's an HTTP request to a URL and a check that the response code and body look right. At its most complex, it's a headless browser stepping through a multi-page workflow and measuring how long each step takes.
Common check types, roughly in order of complexity:
- ICMP ping — is the host reachable at the network layer at all?
- TCP port check — did the handshake complete on the expected port (80, 443, 22, a database port)?
- DNS check — does the domain resolve to the expected record?
- HTTP/HTTPS check — did the request return the right status code, within an acceptable time, with the right content?
- TLS/certificate check — is the certificate valid and not close to expiry?
- Scripted browser transaction — does a full user journey (login, search, checkout) complete correctly end to end?
Our guide on ping vs HTTP vs HTTPS monitoring goes deeper on what each individual check type actually proves and where each one falls short on its own.
Most platforms run the same check from multiple regions simultaneously and only fire an alert once more than one location — or several consecutive runs — fail. That pattern exists because a single probe having a bad moment on its own network is far more common than your service actually being down, and requiring agreement across locations cuts down on false-positive pages at 3am.
Synthetic monitoring vs real user monitoring (RUM)
The two approaches answer different questions, and most serious monitoring setups use both.
| Synthetic monitoring | Real user monitoring (RUM) | |
|---|---|---|
| Data source | Scripted checks you define | Actual visitor sessions |
| Works with zero traffic | Yes | No — needs live users |
| Consistency | Same test, same conditions, every run | Varies by device, network, location |
| Best for | Uptime, SLA tracking, pre-release testing | Real-world experience, actual bottlenecks |
| Catches issues before users see them | Yes | No — reports after the fact |
| Setup | Define the check once | Requires traffic + tracking script |
RUM tells you what actually happened to real people on real devices — useful for understanding whether your slow mobile checkout page is genuinely hurting conversions. Synthetic monitoring tells you what would happen to anyone, right now, under controlled and repeatable conditions — which is exactly what you need for uptime SLAs, since you can't wait for a customer to notice.
TipUse synthetic checks to catch outages fast and consistently; use RUM (if you have the traffic to support it) to understand real-world performance variance across devices and regions.
When should you use synthetic monitoring?
Synthetic monitoring earns its keep in a few specific situations:
- Before you have meaningful traffic. A new site, a staging environment, or a low-traffic internal tool has no RUM data to work with — synthetic checks are the only option.
- For SLA and uptime reporting. If you're promising 99.9% uptime, you need a consistent, external measurement, not a sample of whatever traffic happened to hit the site.
- For critical, low-frequency paths. Password reset, checkout, API authentication — flows that matter a lot but might not get hit often enough for RUM to catch a break quickly.
- For dependency and third-party checks. DNS resolution, certificate expiry, mail routing (MX) — none of these show up in a user's browser session, but a broken one takes your service down anyway.
- For multi-region validation. Confirming your CDN or DNS setup actually resolves and responds correctly from Sydney and not just from your office in London.
A basic HTTP check every minute is a reasonable baseline for almost any public-facing service. Layer in TLS/certificate checks and DNS checks around it, since expired certificates and broken DNS are two of the most common — and most preventable — causes of downtime.
A simple example
A minimal synthetic check configuration for a login endpoint might look like this:
Check type: HTTPS GET
URL: https://app.example.com/api/health
Expected status: 200
Expected body contains: "status":"ok"
Timeout: 10s
Interval: 1 minute
Locations: London, Frankfurt, N. Virginia, Singapore
Alert if: fails from 2+ locations, or fails 3 consecutive times
That single check will catch a crashed process, a broken deploy, a DNS misconfiguration, or a certificate that quietly expired overnight — all without waiting for a customer to file a support ticket.
WarningA check that only verifies a 200 status code can still pass while the page underneath is broken. Assert on actual response content, not just the status code, for anything business-critical.
Where synthetic monitoring fits with your other checks
Synthetic monitoring is one layer of a wider observability stack, not a replacement for the others. It pairs naturally with certificate expiry tracking, DNS health checks, and infrastructure change alerts — our post on website monitoring explained covers how uptime, performance and SSL checks work together, and infrastructure drift detection covers catching unexpected config changes that synthetic checks alone might miss.
InfraNest's monitoring runs scheduled HTTP, TCP and SSL synthetic checks across your domains and servers from a single dashboard, alongside your DNS and certificate management — so the same place that tells you a check failed can also tell you whether a DNS change or an expiring certificate caused it.
Frequently asked questions
#Is synthetic monitoring the same as uptime monitoring?
Uptime monitoring is a common use case for synthetic monitoring, but synthetic monitoring is the broader technique — it also covers scripted transaction tests, DNS checks, and certificate expiry checks, not just "is the site up."
#How often should synthetic checks run?
A simple HTTP or ping check every 1-5 minutes is a reasonable baseline for most public-facing services; scripted multi-step browser checks are usually run less often, such as every 5-15 minutes, since they take more resources per run.
#Can synthetic monitoring replace real user monitoring entirely?
No — synthetic monitoring tells you what would happen under controlled conditions, while RUM tells you what actually happened to real visitors on real devices; most production setups benefit from both.
#Do synthetic checks need to run from multiple locations?
Running the same check from several regions helps you tell a real outage apart from a single probe's local network issue, and most platforms only alert once multiple locations agree the check has failed.
Was dit artikel nuttig?
