--- title: Synthetic Monitoring: API, Browser & Core Web Vitals Checks description: Synthetic monitoring: scripted API, Playwright browser and Core Web Vitals checks on a schedule from a 20-location fleet, alerting only on confirmed failures. canonical: https://watchfor.io/synthetic-monitoring --- # Synthetic monitoring: find out before your customers do Synthetic monitoring runs scripted checks that act like a user, on a schedule and from many locations, whether or not anyone is visiting. WatchFor does it with three check types (API checks, Playwright browser checks and Core Web Vitals audits) on top of plain uptime checks, and opens an incident only when a failure is confirmed. [Start free](/auth/sign-up)[View pricing](/pricing) Every plan includes HTTP, API and Playwright browser checks ; Core Web Vitals monitoring starts on Pro. A failed browser check run: the step that broke, the error and the page at that moment. ## Three checks, three questions Each one catches a failure the others can’t see. Most teams run all three on the paths that matter. [### API checks Does the API still return the right answer?A real request with your method, headers, body and auth. Assertions on JSON fields (JSONPath), headers and body text, and numbers from the response turned into charts you can alert on.What it catchesA 200 with the wrong body: a status field flipped to “degraded”, an empty list, a total of zeroSlow responses and expiring certificates, on the same checkA value such as queue depth crossing your thresholdLearn more](/api-monitoring)[### Playwright browser checks Can a customer still sign in, search and check out?A plain Playwright Test file runs in a real Chromium on a schedule. Each step gets its duration and a screenshot, failed runs keep a trace, and secrets are masked in every artefact. Test the script once before you save it.What it catchesA login, search or checkout that breaks while the homepage still returns 200The step that failed, with the error and the page at that momentSteps that get slower than the budget you set for themLearn more](/playwright-monitoring)[### Core Web Vitals Is the page still fast and stable?A Lighthouse audit of one page in a real headless Chromium, with a desktop or mobile profile. LCP, CLS, Total Blocking Time and the category scores tracked over time, with a screenshot and the full report.What it catchesLCP or CLS drifting into Google’s “Poor” band after a deployHeavy JavaScript or a third-party script blocking the main threadA falling performance or SEO scoreLearn more](/core-web-vitals-monitoring) [### Start with uptime The simplest synthetic check is an HTTP check: request a URL from several locations and check the status code, response time and content. It answers “is it up?” and is where most teams begin.HTTP monitoring](/http-monitoring) ## Synthetic vs real user monitoring Two ways to watch a site, answering different questions. WatchFor does the first one. ### Synthetic monitoring What WatchFor does Our probes run the same scripted check from the locations you pick, on a schedule. It works at 3 a.m. with no traffic at all, every run is comparable with the last, and a broken journey is an alert before it is a support ticket. It only sees the paths you script. ### Real user monitoring (RUM) Not offered A script on your pages collects timings from visitors’ own browsers: real devices, real networks and pages nobody scripted, including field metrics such as Interaction to Next Paint. It only learns about a problem once people run into it. WatchFor doesn’t do RUM; run it alongside, from your analytics or a RUM tool. [Synthetic vs RUM, in detail →](/blog/synthetic-vs-real-user-monitoring) ## How synthetic checks run in WatchFor One platform for every check: the same locations, the same confirmation, the same incidents ### Run from many locations WatchFor runs its own probes in 20 locations across 7 regions. You pick whole regions or exact cities per monitor, within the regions your plan allows (see the table below). Browser checks and Core Web Vitals audits run from the locations that have a browser. ### Alerts on confirmed failures One failed check marks a monitor Degraded and starts re-checks from its other locations. An incident opens only at the rule’s threshold, 3 failed checks in a row by default. A browser check retries once, then confirms with a second run. [How a failure becomes an incident](/docs/monitors/scheduling#how-a-failure-becomes-an-incident). ### Results down to the step API checks list every assertion with the expected and the actual value. Browser checks show each test.step with its time and screenshot, plus a Playwright trace for failed runs. Core Web Vitals audits keep a screenshot, a filmstrip and the full Lighthouse report. ### Test before you save Send an API request once from a real probe and click any field in the response to assert on it or chart it. Run a browser check script once from a browser location and watch the steps pass before anything is scheduled. ### Incidents and on-call A confirmed failure becomes an [incident](/incident-management), goes to your [notification channels](/alerting-integrations), pages whoever is [on call](/on-call) and can show on your [status page](/status-pages), the same as every other monitor. ### Prometheus and Grafana GET /v1/metrics answers in the Prometheus text format: every monitor’s status, open incidents and uptime, synthetic checks included, with a ready-made Grafana dashboard. On the Pro and Business plans. [Scrape it](/docs/api/prometheus). ## Synthetic checks by plan The same limits as the pricing page. HTTP and API checks count toward the plan’s monitor quota; browser checks and Core Web Vitals pages have their own. Plan Regions per monitor HTTP and API checks Playwright browser checks Core Web Vitals pages Free 1 Up to 15 , every 3 min 1 , hourly Not included Starter 2 Up to 50 , every minute 2 , every 10 min Not included Pro 3 Up to 100 , every minute 10 , every 5 min 15 Business All 7 Up to 250 , every 30 s 25 , every minute 30 [Compare every plan →](/pricing)[Browser check runs and run length by plan →](/playwright-monitoring) ## Frequently asked questions Synthetic monitoring, in plain terms What is synthetic monitoring? Synthetic monitoring means running scripted checks that behave like a user, on a schedule, from several locations: request a URL, call an API and check the answer, sign in and reach the checkout, or load a page and measure how fast it renders. Because the checks run whether or not anyone is visiting, a broken login or a wrong API response is found before a customer reports it, and every run can be compared with the last one. What is the difference between synthetic and real user monitoring? Synthetic monitoring runs the same scripted check from known locations on a schedule. It works with no traffic at all and is predictable enough to alert on, but it only sees the paths you script. Real user monitoring (RUM) collects timings from your visitors’ own browsers, so it covers real devices, networks and pages nobody scripted, including field metrics such as Interaction to Next Paint, but it only learns about a problem once people hit it. WatchFor is a synthetic monitoring tool and does not offer RUM. The two work well together. Which synthetic check should I start with? Start with an HTTP check on the pages that must be up: it tells you within minutes when a site stops answering. Use an API check where the content of the response matters. Add a Playwright browser check for the two or three journeys that make you money, such as sign-in and checkout. Add Core Web Vitals monitoring for the pages whose speed affects search ranking and conversions. Which plans include browser checks and Core Web Vitals? Every plan includes Playwright browser checks, Free included: Free 1 (hourly, one location); Starter 2 (every 10 min); Pro 10 (every 5 min); Business 25 (every minute). Core Web Vitals monitoring starts on the Pro plan (Pro 15 pages, Business 30 pages). HTTP and API checks are on every plan and count toward the plan’s monitor quota. The table above and the pricing page have the exact limits. How do you avoid false alarms? A single failed check never opens an incident. It marks the monitor Degraded and starts confirmation re-checks that rotate through the monitor’s locations; an incident opens only when the alert rule’s threshold is reached, 3 failed checks in a row by default. A browser check retries a failed test once inside the run, reports a pass on the retry as flaky, and confirms a failure with a second run about a minute later, from another location when the check has one. Core Web Vitals audits have no fast re-checks; their rules evaluate on the normal interval. Can I use the Playwright tests I already have? Usually, yes. A browser check is one Playwright Test file in TypeScript or JavaScript with up to 10 tests, run by the real @playwright/test runner. test.step, expect, fixtures and request work as they do locally, and npx playwright codegen output works as it is. We supply the config (Chromium, one worker), there is no npm install, and runs reach the public internet only. ## From our blog Guides, deep-dives, and best practices from the WatchFor team [Monitoring ### Synthetic vs Real User Monitoring (RUM): what's the difference? Jun 06, 2026·4 min readRead article](/blog/synthetic-vs-real-user-monitoring)[Monitoring ### How to monitor a login with 2FA (TOTP) in Playwright Sep 29, 2026·5 min readRead article](/blog/monitor-a-2fa-login-with-playwright)[Monitoring ### API monitoring beyond status codes: assert on the response, chart what matters Aug 09, 2026·6 min readRead article](/blog/api-monitoring-beyond-status-codes) ## Script the journey your customers take Start with an HTTP or API check in a minute, add a browser check from an example that already passes, and get one confirmed alert when something breaks. No credit card required. [Start free](/auth/sign-up)[View pricing](/pricing) --- Canonical page: https://watchfor.io/synthetic-monitoring · Site guide: https://watchfor.io/llms.txt