Synthetic Monitoring Tools for Website, API, and SSL Checks From 6 Regions
Uptimehub runs the availability layer of synthetic monitoring: scripted external checks against the endpoints your customers depend on, executed every minute from 6 regions, with no agent to install and no per-seat pricing.
Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
In short
Synthetic monitoring is the practice of running scripted, automated checks against a website, API, or service on a fixed schedule from outside your infrastructure, so you find failures without waiting for a real user to hit them. The traffic is generated by the monitoring tool rather than by visitors, which is why it works at 3am, on a staging environment, and on a page nobody has loaded all week. It splits into two layers: availability and protocol checks (HTTP, keyword, API, SSL, DNS, TCP port, heartbeat), and scripted browser checks that replay a full user journey such as login or checkout. Uptimehub covers the first layer, checking every minute from 6 global regions and confirming any failure across regions before it alerts you, on flat per-monitor pricing rather than a per-test-run meter.
What you get
Synthetic monitoring for developers, SaaS teams and agencies
Checks run whether or not anyone visits
Synthetic checks generate their own traffic, so a broken endpoint on a low-traffic API or a staging environment surfaces on the next interval instead of the next complaint.
6 regions with cross-region confirmation
Every check runs from multiple locations and a failure is retried elsewhere before it counts, which catches regional routing and CDN faults without generating false alarms.
Seven check types in one flat plan
HTTP, keyword, API, SSL, DNS, TCP port, and cron heartbeat checks are all included, so you cover the whole surface without upgrading tiers to unlock a protocol.
Priced per monitor, never per test run
Tightening a check from 5 minutes to 1 minute multiplies your bill on a per-run meter. Here the price is the same, so you can monitor at the interval the service deserves.
How it works
From URL to alert in four steps
Pick the endpoint and the check type
Point a check at a URL, an API route, a hostname, or a port. Add an expected keyword or status code if the response body matters.
Set the interval and the regions
Choose how often the script runs and which of the 6 regions execute it. Revenue-critical endpoints belong on a one minute interval.
Confirm before alerting
A failure is retried from other regions first, so what reaches Slack, email, SMS, or webhook is a confirmed fault rather than a blip.
Report the result
Every run feeds uptime history, response time trends, and your branded public status page automatically.
On this page
What are the types of synthetic monitoring?
The phrase covers everything from a one line HTTP request to a scripted browser walking through checkout, and vendors use the same word for all of it. That is the main reason quotes for "synthetic monitoring" vary by an order of magnitude. Here is what the categories actually are and what each one earns its keep on.
| Check type | What it simulates | What it catches | Typical interval |
|---|---|---|---|
| Uptime / HTTP check | A visitor requesting a page | Outages, 5xx errors, timeouts, unexpected status codes | 30 to 60 seconds |
| Keyword check | A visitor reading the page | Pages that return 200 but render an error or an empty template | 1 to 5 minutes |
| API check | A client calling an endpoint | Broken auth, changed response schemas, slow or failing JSON | 1 to 5 minutes |
| SSL and DNS checks | The handshake and lookup that happen before any request | Expiring certificates, hijacked or misconfigured records | Hourly to daily |
| TCP port check | A service accepting a connection | Databases, mail servers, and socket services that are not HTTP | 1 to 5 minutes |
| Heartbeat / cron check | A scheduled job reporting that it ran | Backups and cron jobs that failed silently | Per job schedule |
| Scripted browser / transaction check | A full user journey in a real browser | Broken checkout flows, login regressions, front end JavaScript faults | 5 to 15 minutes |
Being straight about it: Uptimehub covers the first six rows. We do not run scripted Playwright browser journeys, so if replaying a multi step checkout is your main requirement, a code first tool is the better fit and we say as much on our Checkly alternative page. What most teams need first is the availability layer, because the overwhelming majority of customer facing incidents are an endpoint being unreachable, slow, or returning the wrong thing, not a subtle regression on step four of a form. Start there, add browser scripts later if the funnel justifies the maintenance.
Synthetic monitoring vs real user monitoring: what is the difference?
Synthetic monitoring measures a test you wrote. Real user monitoring (RUM) measures what actual visitors experienced. They answer different questions and neither one replaces the other.
| Synthetic monitoring | Real user monitoring (RUM) | |
|---|---|---|
| Data source | Scripted checks you control | Telemetry from real visitor sessions |
| Works with zero traffic | Yes | No, it needs real users |
| Detects a full outage | Yes, within one check interval | Poorly, an outage looks like missing data |
| Covers staging and pre-production | Yes | No, production only |
| Reflects real devices and networks | No, conditions are fixed by design | Yes, that is the entire point |
| Comparable baseline over time | Yes, the test is identical every run | No, the mix of users shifts constantly |
| Requires code on your site | No | Yes, a JavaScript snippet |
| Best used for | Alerting, availability, SLA evidence | Core Web Vitals, experience trends, front end tuning |
The distinction that matters at 3am is this: RUM tells you users are having a bad time, synthetic tells you the service is unreachable, and only one of those fires when there are no users awake to have a bad time. RUM also goes quiet during the worst outages, because a site that will not load sends no telemetry. If you are choosing what to buy first and your product is not yet at high traffic, buy the synthetic checks. We go deeper on the boundary between these approaches in synthetic monitoring vs uptime monitoring.
How much do synthetic monitoring tools cost?
Sticker prices are not the useful comparison here, because the four common billing models behave very differently as you scale. Published rates also change, so check the current page before you sign anything. What does not change is the shape of each model.
| Pricing model | How it is billed | Where it bites |
|---|---|---|
| Per test run | A rate per thousand or ten thousand executions, usually with browser runs priced far above API runs | Cost scales with interval. Moving a check from 5 minutes to 1 minute multiplies that line item by five |
| Per host or infrastructure unit | Synthetics sold as a module on an APM or observability contract | You buy the whole platform to get the checks, and the platform is the expensive part |
| Per seat | Charged per user with dashboard access | Letting support and account managers see status raises the bill without adding a single check |
| Flat per monitor | One price per endpoint, with check types, regions, and users included | Predictable. The bill only moves when you add endpoints |
Run the arithmetic on the per-run model before you commit to it, because it is the one that produces surprise invoices. A single check at one minute intervals is 1,440 runs a day, roughly 43,800 a month. Fifty endpoints at that interval is about 2.19 million runs a month, and multi-region execution multiplies it again: the same fifty endpoints checked from 6 regions is over 13 million runs. That is the mechanism behind the "our monitoring bill is bigger than our hosting bill" story you hear from teams on usage-metered plans, and it quietly pushes people to monitor less often than they should. Uptimehub prices per monitor with all 6 regions and every check type included, which is a deliberately boring model: you decide the interval based on how much downtime you can tolerate, not on what it does to the invoice. Full detail on our pricing page.
Synthetic monitoring best practices
Most of the value comes from a handful of decisions made when the checks are set up, not from the tool you picked.
- Monitor the endpoint that earns money, not the homepage. A marketing page returning 200 says nothing about whether login, checkout, or the API is healthy. Give each revenue-critical path its own check.
- Assert on the response, not just the status code. Half of the ugly incidents return a perfectly valid 200 with an error page, an empty result set, or a stale cache behind it. A keyword assertion or a JSON field check turns those into alerts.
- Check from more than one region, and confirm before paging. Single-location monitoring both misses regional faults and invents outages that never happened. Cross-region confirmation is the cheapest false-alarm filter there is.
- Match the interval to your availability target. A 99.99 percent monthly SLA allows about 4 minutes of downtime, so a 5 minute check interval cannot even detect a breach. Our SLA monitoring page has the full allowance table.
- Monitor the third parties you depend on. Payment gateways, auth providers, and shipping APIs take your product down with them, and you will want your own timestamped record when you open the ticket.
- Watch the slow degradation, not only the hard failure. Response time creeping from 300ms to 4 seconds loses customers without ever tripping an up-or-down check. Alert on latency thresholds as well as availability.
- Keep the alert set small enough to trust. A channel that cries wolf gets muted, and a muted channel is worse than no monitoring at all because it feels like coverage.
Who needs synthetic monitoring?
Four situations turn this from a nice idea into an operational requirement.
You run an API that other companies build on. API traffic is bursty and machine driven, so an auth or schema break can sit undetected for hours before a customer notices. Scheduled API checks with response assertions are the only thing that catches it early.
You sell with an uptime commitment. A contractual availability number needs an independent, continuously running external measurement behind it, kept as evidence rather than reconstructed after the fact.
You are an agency or MSP responsible for sites you did not build. Client sites break in ways you do not control: an expired certificate, a DNS change made by someone at the client, a plugin update at 2am. Per-client checks and per-client status pages are what turn that into a managed service instead of a fire drill. See monitoring for agencies.
Your traffic is too low or too spiky for RUM to help. B2B tools, internal apps, and seasonal ecommerce all have long quiet stretches, and real user data cannot tell you about an outage that happened while nobody was looking.
In every case the requirement is the same: checks that run on their own schedule from outside your infrastructure, from enough places to be trusted, with a retained history. That is what Uptimehub does, at a flat per-monitor price that does not penalize you for checking often or for adding the people who need to see the results. Start with uptime monitoring on your critical paths, add SSL certificate monitoring so a renewal never takes you offline, and publish the outcome on a branded status page.
FAQ
Questions buyers ask about Synthetic monitoring
Synthetic monitoring runs scripted, automated checks against a website, API, or service on a fixed schedule from outside your infrastructure. The traffic is generated by the monitoring tool rather than by real visitors, so problems surface even when nobody is using the service. It is the standard way to detect outages, certificate expiry, and broken API responses before customers report them.
Synthetic monitoring runs a test you defined on a fixed schedule and works with zero traffic. Real user monitoring collects data from actual visitor sessions and needs real traffic to produce anything. Synthetic is better for alerting, availability, and SLA evidence. RUM is better for Core Web Vitals and understanding real device and network conditions. Most mature teams run both.
Full outages, slow responses, incorrect HTTP status codes, pages that return 200 with an error rendered inside them, expiring or invalid SSL certificates, DNS misconfiguration, closed TCP ports, failed API authentication, changed response payloads, and cron jobs that stopped running. Multi-region checks additionally catch faults that only affect visitors in one part of the world.
Synthetic transaction monitoring is the subset that replays a multi step user journey, such as logging in, adding an item to a cart, and completing checkout, usually in a scripted real browser. It catches broken flows that a single page request would pass. It costs more to run and needs maintenance every time the interface changes, so most teams add it after their availability checks are solid.
Once a minute for anything that generates revenue, because the interval sets the ceiling on how long an outage can run before you know. Five minutes is acceptable for low-stakes pages. Certificate and DNS checks can run hourly or daily. If you carry a 99.99 percent availability target, one minute is the minimum that can detect a breach at all.
No. APM instruments your application from the inside and traces requests through your own code, database calls, and services. Synthetic monitoring probes the finished service from the outside with no code installed. APM explains why something is slow once you know it is slow. Synthetic monitoring is what tells you, and it keeps reporting when the application is too broken to send traces.
Last updated July 2026
More monitor types
Start monitoring in two minutes
Add a URL or endpoint and Uptimehub checks it every minute from 6 global regions, alerts you in seconds, and updates your branded status page. Read-only checks that never touch your servers.