What is Synthetic Monitoring? Definition, Types, RUM Comparison

What is synthetic monitoring?

Synthetic monitoring runs scripted checks against a website, API or application on a schedule, from locations you choose, and alerts you when a check fails or slows down. The traffic is artificial, so it works at 3 a.m. and before launch, with no visitors needed. It answers one question continuously: does this still work the way we designed it?

This page explains the concept. To set up checks, see LoadFocus synthetic monitoring, which covers API checks and Playwright browser checks.

How synthetic monitoring works

1. Define a check. A URL, an API request or a scripted browser journey, plus assertions: status code, text in the body, response time under a limit.
2. Schedule it. Every minute for critical services, every few minutes for most, hourly or daily for low-priority pages.
3. Run it from several locations. A failure seen from one region and not another points to routing, CDN or DNS trouble. Requiring two locations to agree also cuts false alarms.
4. Record the result. Timings, status, and for browser checks screenshots and network waterfalls.
5. Alert. Send email, Slack, a webhook or a pager message, optionally only after several consecutive failures.

Types of synthetic checks

• Uptime checks. Request a URL and confirm it answers with the expected status.
• API checks. Call an endpoint with headers and a body, then assert on status, headers, payload and timing. Multi-step checks chain calls, for example log in, take the token, call a protected endpoint. See API monitoring.
• Browser checks. Drive a real browser through a page or a user journey such as sign-in, search and checkout, and report which step failed or slowed.
• Page speed checks. Load a page in a lab setting on a schedule and track metrics like Largest Contentful Paint and Total Blocking Time. See Core Web Vitals.
• SSL and DNS checks. Watch certificate expiry and confirm a hostname resolves to the right address.

Synthetic monitoring vs real user monitoring

They measure different things, and mature teams run both.

The longer comparison is in synthetic monitoring vs real user monitoring.

Metrics worth tracking

• Availability. The share of checks that passed in a period. Availability targets such as 99.9% are usually reported from this number.
• Response time. End to end, ideally split into DNS, connect, TLS, wait and download.
• Error rate. Failed assertions and unexpected status codes.
• Time to first byte. A quick signal of server health.
• Browser metrics. LCP, CLS and TBT in browser or page speed checks. Interaction to Next Paint needs real users, so TBT stands in for responsiveness in lab runs.

A simple example

An online shop adds one API check for GET /products?limit=1 that must return 200 with a JSON body containing items in under 500 ms, and one browser check that walks sign-in, search and add to cart. Both run every few minutes from two regions. When the cart step starts failing after a deploy, the alert names the step and attaches the screenshot, before most customers hit it.

Common mistakes

• Checking only the homepage. The homepage can be up while login or checkout is broken.
• Asserting status only. A 200 with an error message or empty list still passes. Assert on the body too.
• One location. A local network blip pages you at night.
• Alerting on every failure. Require two consecutive failures or two locations to agree.
• Shared test accounts that expire. The check starts failing for reasons unrelated to the product.
• Treating it as full coverage. It does not replace observability or application performance monitoring, which explain why something broke.

Synthetic monitoring and load testing

Synthetic checks send a trickle of traffic to confirm that one user can do the job. A load test sends many users at once to find where the system breaks. They complement each other: a load test finds the limit before launch, and synthetic monitoring tells you when production drifts toward it. Free API checks on LoadFocus run every 5 minutes; API monitoring lists the paid intervals, and page speed monitoring covers scheduled Lighthouse audits. Start with free API checks. For practical tips, read how to improve user experience with synthetic monitoring.

FAQ: Synthetic Monitoring

What is the difference between synthetic monitoring and uptime monitoring?

Uptime monitoring is the simplest synthetic check: it asks whether a URL responds. Synthetic monitoring also covers API assertions, multi-step journeys, browser checks and performance timings.

How often should synthetic checks run?

Every minute or two for revenue-critical endpoints, every five minutes for most services, and hourly or daily for slow-changing pages. Shorter intervals find problems sooner but cost more runs.

Does synthetic monitoring replace real user monitoring?

No. Synthetic monitoring tells you something is broken, even with no visitors. RUM tells you how real people on real devices experience the site. Use both.

Can I use synthetic monitoring before launch?

Yes. Because it needs no visitors, you can point checks at a staging environment and run them after each deploy.

Why run checks from several locations?

To separate a real outage from a local network problem, and to spot regional issues with DNS, CDN or routing that a single location would miss.