What Is Synthetic Monitoring? A Practical Guide

It is 03:00. Nobody is using the application, the servers are comfortably underloaded, and a DNS change has quietly made the API unreachable. Your first customer should not have to double as your first monitoring agent.

Synthetic monitoring sends scheduled requests or runs predefined interactions against a service, then checks the result against an expected outcome. It creates its own test traffic, so it can collect evidence even when real users are asleep. The word “synthetic” describes the traffic. The timeout is quite real.

What synthetic monitoring actually measures

A useful synthetic check has four ingredients: an action, a location, an expectation and a schedule. For example: request an API’s readiness endpoint from the branch network every minute, expect HTTP 200 and a JSON value of true, and record how long the request takes.

That is a repeatable experiment. When the result changes, you know which expectation failed and where the request came from. A graph of CPU usage tells a different story: what the machine was doing while the experiment succeeded or failed. Both stories are useful.

A synthetic check can detect a problem before the next real visitor encounters it. It cannot guarantee that outcome: a failure may begin between checks, affect a location you do not test, or occur in a workflow outside your coverage.

There is more than one level of synthetic testing

• Network checks test a specific dependency, such as DNS resolution or whether a TCP connection can be established.
• HTTP and API checks send a request and inspect the response: status, content, JSON values, headers, certificate information and timing.
• Browser checks use a browser to load pages, execute JavaScript and follow a scripted journey, such as signing in and opening a report.

These levels answer different questions. A listening port does not prove that an API returns useful data. A correct API response does not prove that a JavaScript button works. A successful browser journey covers the path you scripted, not every action a customer could take.

How it fits alongside RUM, metrics and load testing

Real user monitoring, or RUM, collects measurements from actual user sessions. It helps explain which devices, pages and experiences real visitors encounter. Synthetic monitoring runs controlled tests whether or not someone visits. One gives you observed customer experience; the other gives you repeatable samples under chosen conditions.

Infrastructure metrics, logs and traces help investigate the reason for a failed sample. A synthetic check may establish that the catalog endpoint timed out; application telemetry can help explain whether it waited for a database, exhausted a connection pool or hit another dependency.

Load testing has another purpose: testing behavior under a chosen volume of traffic. Running an availability check every minute is not a capacity test. Increasing the number until somebody complains is not a particularly good capacity test either.

Build one useful synthetic check in RMON

Suppose a service you control exposes a read-only endpoint at https://catalog.example.com/ready. This is an illustrative address; replace it with your own. Its response is:

{
  "service": "catalog",
  "ready": true
}

The service team must define what “ready” means. Perhaps it includes a lightweight dependency check. If the endpoint always returns true, the monitor will faithfully report that your constant still works.

1. Open Dashboard → Add check. Choose HTTP(s), enter the URL and select the intended agents under Run checks from.
2. On Settings, choose GET and accept 200. Add a JSON Path body condition for $.ready with the expected JSON boolean true.
3. Keep certificate verification enabled. If the final destination must be encrypted, choose Require HTTPS on a compatible agent.
4. Choose an interval, request timeout and retry count appropriate to the service. The first-check walkthrough provides an initial configuration to adapt.
5. On Notifications, select a tested destination and add a runbook. Save, then confirm fresh results from every intended location.

Use the HTTP check guide for authentication, headers and request options. An HTTP response-time measurement covers that request; it is not a measurement of a fully rendered browser page.

Choose locations and frequency deliberately

An agent near the service provides a useful internal view. An agent on a user network tests a different route. Comparing them can show whether a symptom appears in one place or several. Location selection should follow the people and systems that depend on the service.

Frequency has a cost. In an idealized schedule, one request every minute from two locations means 2,880 scheduled requests per day, before retries and additional requests caused by redirects. Keep checks lightweight, respect API limits and avoid operations that create orders or send real messages.

Do not promise a detection time from the interval alone. Request duration, retries, scheduling, result delivery and notification delivery also matter. Measure the full path with a controlled failure.

Prove that failure and recovery are visible

Use a disposable endpoint to return "ready": false while keeping HTTP 200. Confirm that the body condition fails and that the assigned destination receives the incident. Restore true and verify a fresh successful result and recovery notification.

Check timestamps throughout. A stale green result can mean that measurements have stopped arriving. Also record the experiment’s limits: the locations used, the request made and the dependency behavior the endpoint actually tests.

Start with one important service and expand around concrete failure modes. Synthetic monitoring earns its place by asking a useful question repeatedly and making a changed answer visible to the person who can act on it.

For the broader distinction between protocol and scripted checks, see the primary documentation for scheduled synthetic canaries and API and browser synthetic monitoring. For your RMON setup, continue with the setup guide.