What it is
Synthetic monitoring is a set of scripted checks that run on a schedule and act like a customer or a client. Each check follows a fixed path: open the login page, send a request, add an item to a cart, read the response. The check runs from a probe outside your network and records whether the path worked, how long it took and where it failed.
It is not real user monitoring. Real user monitoring watches actual browsers and apps. Synthetic monitoring uses a known script and a known test account, so you can compare runs and spot a break before a customer reports it. It also covers paths that real traffic may not hit at 3 a.m., such as a nightly export.
Think of it as a smoke test for the business, not a full test suite. A good check answers one question: can a customer complete this task right now? A server can be up and still fail to log people in.
How it works
Most tools offer three check types. An uptime check sends an HTTP request and checks the status code, DNS resolution, TLS certificate and response time. An API check sends headers and a body, then asserts on a JSON field or status code. A browser check drives a headless browser through a full path, such as sign in, search, open a product and start checkout.
You choose where the checks run. Public probes in several regions show whether a problem is local or global. Private probes inside your network check internal services. Frequency matters: a check every minute catches fast breaks; a check every 15 minutes costs less and still catches most outages. Set timeouts and one retry so a slow response does not wake someone up.
Each check needs assertions and a clear failure message. Assert on a visible element, a JSON value or a redirect, not just a 200 status. Store credentials in the tool's secret store, not in the script text. Use a dedicated test account with the smallest permissions that still lets the path run. Add maintenance windows so planned releases do not create false alarms. Alerts should route to the team that can fix the problem, with a link to the failing step and a screenshot from browser checks.
Why it matters for a business
Synthetic monitoring gives you an early warning on the paths that bring in money. Sign-in, search, checkout and payment are common choices. If checkout fails at 2 p.m., you want to know from a probe, not from a customer email. The check also verifies dependencies you do not control, such as a payment provider, a DNS host or a certificate authority.
It supports release checks. After a deploy, run the same checks against production and compare the result with the baseline. If the login page renders but the submit button does nothing, a browser check catches it. A status page can show the result, and the on-call engineer gets a signal that points to the failing step.
It does not replace logs, traces or real user monitoring. Those show why something broke and who was affected. Synthetic checks show that a known path is broken now, from a known place, with a known script. Use them together: the check opens the incident, the traces explain it. For managers, the value is a shared definition of working for critical journeys.
Common mistakes
The first mistake is checking only the home page. A home page can return a 200 while login, search and checkout are broken. Pick the journeys that matter and assert on the step that proves the journey worked.
The second is too many alerts. A check that fires on every slow response creates noise, and people start ignoring it. Set thresholds that match the user experience, use retries for short blips and route alerts to an owner. Review noisy checks and fix or remove them.
The third is fragile test data. Shared test accounts get locked out, passwords expire and test cards get declined. Create a dedicated account, rotate its secret on a schedule and keep test data clean. Browser checks that depend on a CSS class or a label break when the front end changes. Prefer stable test IDs and review checks after a redesign.
The fourth is testing from the wrong place. A check from your office network can pass while customers in another region fail. Run public checks from the regions your customers use. Do not put secrets in script text or screenshots. A passing check is not proof that every user is fine.
How to get started
Start with a short list. Pick three to five journeys: sign in, search, add to cart, checkout, password reset. For each one, write the steps a customer takes and the one assertion that proves success. Note the dependencies: DNS, TLS, identity provider, payment API, database.
Run the checks in staging first. Confirm the test account works and the assertions fail when they should. Then enable them in production at a frequency you can afford, often one to five minutes for the top journey and longer for the rest. Set a timeout, one retry and a clear alert route. Write a one-page runbook for each check.
Review results weekly for the first month. Remove checks that never fail or that fail for reasons nobody acts on. Add a check when a new critical path appears. Keep the test account and test data in a known state, and review checks after major front end work.
If you need the surrounding release platform, Cloudverg's Delivery platform setup is $14,500/month and includes pipelines, environments, monitoring and rollback for the services in scope. Other options are a standalone synthetic monitoring service or an open source probe you host yourself. The right choice depends on how many journeys you need to watch and who will respond when a check fails.
Frequently asked questions
What is the difference between synthetic monitoring and real user monitoring?
Synthetic monitoring runs a scripted check from a probe you control. Real user monitoring collects data from actual visitors in their browsers and apps. Synthetic checks are repeatable and catch breaks on paths with little traffic; real user data shows what real customers experience.
How often should synthetic checks run?
Run your most important journey every one to five minutes if the tool and budget allow. Run less critical paths every 10 to 15 minutes. Use retries to avoid alerts from a single slow response, and match the frequency to how fast you need to know about a break.
Can synthetic monitoring test logged-in pages?
Yes. Use a dedicated test account with limited permissions and store its credentials in the tool's secret store. The check can sign in, visit a page and assert on content that only appears after login. Rotate the password on a schedule so the check does not fail when the account policy changes.