Synthetic monitoring: definition
Synthetic monitoring uses automated probes to test a website, API or application from controlled environments. A synthetic check can be a simple HTTP request, a DNS or TCP check, or a scripted browser journey that signs in, searches or completes another important workflow.
Why teams use synthetic checks
Synthetic monitoring is repeatable and does not depend on real traffic. It can detect an outage at night, test from multiple regions and continuously validate a critical path even when no customer is currently using it.
Types of synthetic checks
- Protocol checks: HTTP, TCP, ping or DNS validation.
- API checks: request/response assertions, authentication and payload validation.
- Browser checks: scripted navigation and interaction in a real or headless browser.
- Private-location checks: probes inside a network for internal services.
Assertions matter
A status code alone may miss a functional failure. When the business outcome matters, validate expected content, response schema or a multi-step transaction. Keep scripts stable enough that monitoring fails because the service is broken, not because a fragile selector changed.
Locations, frequency and false positives
Probe geography affects DNS, routing and network latency. Use locations that represent important user populations and consider confirmation from more than one probe before paging on a global outage. Check frequency determines how quickly an incident can be detected and how precisely downtime can be estimated.
Synthetic vs RUM
Synthetic monitoring answers “does this controlled test work now?” Real user monitoring answers “what did actual users experience?” The two views are complementary: synthetic checks give repeatability and early detection; RUM shows population-specific impact.
Related concepts
Short answer
Synthetic monitoring runs repeatable automated checks from known locations. Define meaningful assertions, choose representative probes and use confirmation logic so a scripted test represents a real service outcome.
Practical checklist
- Use assertions that represent the real user or service outcome.
- Choose probe locations that reflect important network paths.
- Confirm failures before paging when false positives are costly.
- Keep browser scripts stable and small enough to maintain.