Synthetic monitoring with scheduled HTTP and API probes
UptimePilot runs scripted requests against your website and your APIs on a fixed schedule, from US East and EU Central, and checks every answer against the rules you set. Because the traffic is synthetic, it runs at 3 a.m. on a Sunday just as it does at noon on a Monday, so you learn about a broken endpoint before the first real customer hits it.
What synthetic monitoring means
Synthetic monitoring sends artificial, predictable traffic to a service and measures the result. Every probe is the same request, from the same regions, at the same interval. That consistency is its strength: when a number changes, the service changed, not the visitor.
UptimePilot's synthetic probes are HTTP and API requests. Each probe can check the status code, the response time, the presence or absence of text, and, for APIs, the fields of a JSON response. Probes run every minute on Starter and every 30 seconds on Team, Business and Enterprise.
- HTTP(S) probes on pages and endpoints, with status code and response time thresholds
- Keyword probes that confirm a word or phrase is present, or absent, in the response
- API probes with method, headers, request body and JSON assertions
- Separate probes for each critical step of a flow, such as the login endpoint, the search endpoint and the checkout endpoint
- Multi-region confirmation before any alert is sent
Synthetic monitoring vs real user monitoring
Real user monitoring (RUM) collects timings from actual visitors' browsers through a script on your pages. It shows how real people on real devices and networks experience the site. It needs traffic to say anything, and it says nothing at all when nobody is visiting, or when the page is so broken that the script never loads.
Synthetic monitoring works the other way around. It needs no traffic and no script on your pages. It tells you whether the service works right now, from known locations, under known conditions. It is the right tool for availability alerts, SLA measurement and catching problems after a deploy or overnight.
We want to be clear about scope. UptimePilot does synthetic monitoring only. It does not collect data from your visitors' browsers, it does not run scripted browser sessions, and it does not record clicks. If you need field data on page rendering, use a RUM product alongside UptimePilot. If you need to know within a minute that your login API returns errors, that is what UptimePilot does.
| Synthetic monitoring | Real user monitoring | |
|---|---|---|
| Source of data | Scheduled probes from fixed regions | Visitors' browsers |
| Works without traffic | Yes | No |
| Detects outages at night | Yes | Only if someone visits |
| Consistent baseline | Yes, same request every time | Varies with devices and networks |
| Best for | Availability alerts, SLA reports, API health | Rendering performance in the field |
| In UptimePilot | Yes | No |
How synthetic probes work on UptimePilot
- 01 Choose the probe type: HTTP(S), keyword, or API with assertions.
- 02 Define the request. For APIs, set the method (GET, POST, PUT, PATCH, DELETE), headers, an auth token stored encrypted, and a JSON or form body.
- 03 Define success. Expected status code, a response time threshold, a timeout, and any assertions on the body.
- 04 Set the interval and alerting: who hears about it, on which channel, and who comes next in escalation.
- 05 Link probes to components on your status page, so an outage on the checkout endpoint shows as "Checkout" for your customers.
Each probe runs from US East and EU Central. If one region sees a failure, the other rechecks at once. The monitor is marked down only after confirmation, then the alert goes out, and recovery is reported with the total downtime.
Covering a user flow with chained API requests
Many critical flows are a short series of API calls: authenticate, read the account, submit an order. UptimePilot covers these with separate API probes for each step, each with its own assertions, grouped under one project so the results sit side by side. A failing step shows exactly where the flow breaks, which is often more useful than a single pass or fail for the whole journey. For login steps, store the test account's token in the encrypted credential field, never in the URL.
Assertions that catch silent failures
A 200 status code proves very little. An API can return 200 with an empty array because a cache is cold, or with an error object because an upstream service failed. Assertions close that gap. On UptimePilot you can assert that a JSON field exists, that it equals a value, that it contains a string, or that a number falls within a range. Combine them: status is 200, "items" exists, "items.length" is at least 1, response time is under 800 ms.
For pages, keyword checks do the same job. A product name rendered from the database proves more than text in a static header, because a cached shell can load while the real content is missing.
Thresholds, percentiles and timeouts
Synthetic probes give a clean time series, which makes percentiles meaningful. Watch p50 for the typical response, p95 for one request in twenty, and p99 for the slow tail. Set the alert threshold above normal p95, so ordinary variation does not page anyone, and set the timeout at the point where a user would give up, usually 10 to 30 seconds. Our page on website performance monitoring covers thresholds in more depth, and the api monitoring checklist lists assertions worth adding to every endpoint.
Probe traffic and your analytics
Probe requests are small and regular. At a 30 second interval, one probe produces a few thousand requests a day per endpoint, which is negligible for most services. If your API enforces strict rate limits, give the probe its own token or key, so monitoring traffic never competes with customer traffic.
Which plan fits your synthetic monitoring
| Plan | Monitors | Interval | Data history | Monthly, or billed yearly |
|---|---|---|---|---|
| Starter | 50 | 1 minute | 90 days | $49, or $24 per month yearly |
| Team | 200 | 30 seconds | 1 year | $99, or $49 per month yearly |
| Business | 1,000 | 30 seconds | 2 years | $249, or $124 per month yearly |
| Enterprise | 3,000 | 30 seconds | 3 years | $599, or $299 per month yearly |
Every plan includes HTTP, keyword and API probes with assertions, plus ping, TCP port, SSL, domain and heartbeat monitors. Business adds the REST API for managing monitors and incidents from your own tooling. See pricing for every limit, or api monitoring for API probe details.
01
What is synthetic monitoring?
Synthetic monitoring sends scheduled, scripted requests to a website or API from known locations and checks the results. It detects failures without depending on real traffic.
02
Does UptimePilot run browser scripts?
No. UptimePilot's synthetic probes are HTTP and API requests with assertions. It does not run scripted browser sessions or record clicks. It checks the status, timing and content of the responses your pages and endpoints return.
03
Does UptimePilot do real user monitoring?
No. UptimePilot does synthetic monitoring only and adds no script to your pages. If you need field data from visitors' browsers, use a RUM product alongside it.
04
How do I monitor a login or checkout flow?
Create an API probe for each step, such as the auth endpoint, the account endpoint and the order endpoint, each with its own assertions, and group them under one project. A failure points to the exact step that broke.
05
Where do the probes run from?
From US East and EU Central. A failure in one region is rechecked from the other before the monitor is marked down.
Put a probe on your most important endpoint
Pick the request that would hurt most if it failed tonight, add its assertions and choose who gets the alert. UptimePilot starts probing from two regions right away.