Running & Maintaining a Site

Synthetic Monitoring

Definition

Synthetic monitoring means generating traffic on purpose in order to measure something. An agent — a headless browser, or a plain HTTP client — runs from a set of chosen locations at a set interval, requests your pages, and records what came back. Checks range from trivial to elaborate: a bare request for the home page, a full page load with browser timings, or a scripted sequence that clicks through several steps and asserts that particular text appears. Because device, network and location are held constant, the numbers are comparable week to week, which makes synthetic checks good at detecting change and poor at describing the spread of experiences real visitors have. Its complement is real user monitoring, which measures genuine visits and can say nothing at all when there are none.

Why It Matters

The great advantage is that it does not need anyone to be there. A site with 20 visitors a day can still be checked every minute, which is the only way to know that an outage at three in the morning lasted eleven minutes rather than seven hours. Synthetic checks also catch the failures that never reach a person: a certificate that expired an hour ago, a redirect that now loops, a download returning 403. And because the conditions are fixed, a Core Web Vitals figure from a synthetic run gives a clean before-and-after for a change you just made, in a way that a noisy field measurement does not.

How It Works

A scheduler fires each check on its own interval — commonly one to five minutes for availability, hourly or daily for heavier page-load runs — from agents in several regions. The agent resolves DNS, opens the TLS connection, sends the request and records a timing at each stage, then applies assertions: the status must be 200, the body must contain a given string, the total load must come in under a threshold. A failure from a single location is usually a network problem at that location, so most systems require agreement from two or three agents before alerting, which is what keeps a routing blip from waking someone. This is the same machinery underneath uptime monitoring, with richer assertions layered on top. Scripted checks add browser automation, replaying a click path and failing when an element is missing, and those are the ones that need maintenance every time the page changes.

Real-World Example

A conference publishes its schedule and a 3 MB programme PDF at summit-2026.99helpers.site. One synthetic check requests the schedule page every minute from three regions and asserts that the string holding the opening keynote time is present; a second requests the PDF hourly and asserts its content type and a minimum byte count. When somebody uploads a truncated replacement two days before the event, the byte-count assertion fails within the hour. The page was never down, so a plain availability check would have said nothing at all.

Common Mistakes

  • Checking only that the home page returns 200 — the pages that break are the deep ones, and a status code says nothing about whether the content is right
  • Alerting on a single failing location — one agent's network path fails regularly, and the false alarms train everyone to ignore the alerts that matter
  • Reading synthetic load times as what visitors experience — the agent sits in a data centre on a fast connection and will flatter almost any site

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →