Uptime monitors and synthetic checks do different jobs

Two green lights, two questions

An uptime monitor asks whether a URL answers. A synthetic check asks whether a task can still be finished. They get confused because both can be drawn as a green dot on a timer. The questions are not interchangeable. A site can answer HTTP 200 on / and still refuse every signup. A site can fail a scripted click because you renamed a button, while the server is healthy.

If you only buy one, buy the one that matches the failure you are afraid of. 'The host is down' is an uptime problem. 'A person cannot create an account, log in, or open checkout' is a synthetic problem. Most small teams meet the second one first and own a tool that only detects the first. The signup-specific version of that story is a separate guide. This page is the comparison.

What an uptime check actually does

A typical uptime check sends a request from outside your network and records the status code and how long the response took. Some also search the body for a word. That catches a process that crashed, a DNS record that disappeared, a certificate that the client refuses, and a host that stopped responding. It is cheap, and it should stay.

It does not boot your JavaScript, click, type, or follow a task past the first response. Single-page apps often return the same HTML for every route. The monitor sees 200 and the title, and the route's real work never runs. A keyword that sits in the template, rather than in the result of a click, stays found after the feature broke.

What a synthetic check actually does

A synthetic check is a script run on a schedule from somewhere that is not your laptop. The honest version for a web app is short. Open this URL. Click this control. Type a test value. Expect this sentence. If the sentence is missing, the check fails, including when the first response was 200. One browser, one path, on a timer. That is enough to catch a deploy that shipped a broken task.

It is not a load test. It will not tell you that the site falls over at a hundred concurrent buyers. It is not a security audit. It is also noisier than an uptime ping, because copy changes and slow third parties fail the script. Write the expected sentence so it is true only when the task worked, and update it when you change the product. A pile of paths you do not read is worse than one path you do.

How the failures differ

An uptime failure is usually global. Nobody can load the host, or the certificate is rejected, or the status is 5xx. You look at the platform, DNS, and the process. A synthetic failure is usually local to a path. The homepage loads. Signup, login, or the checkout button does not. You look at the step that failed, the screenshot, and the sentence that was missing.

False greens and false reds swap places. Uptime is falsely green when the server is up and the task is dead. Synthetic is falsely red when the task is fine and the script is stale, or when a captcha or a one-time code blocks the test account. Do not 'fix' a product because a check expected the old heading. Edit the check.

What to run, in practice

Keep an uptime check on the public origin so you hear about an outage where nothing answers. Add one synthetic path for the task that makes the product real: create an account, log in, or open checkout. Add a second path only when the first one has been quiet and useful. WhoopsBot is the synthetic side. It is not a replacement for a ping that only cares whether the host answered.

Put the two alerts in different places if you can. An uptime page that is red means stop and look at the host. A flow failure means open that run, read the step, and look at the screenshot. Mixing them into one 'the site is down' channel trains you to ignore both. If you only have one inbox, keep the subjects different enough that a certificate or a 500 does not look like a renamed button.

The free plan runs one flow once a day and keeps the result on the run page, with no email. Starter is $19 USD a month, five flows about every six hours, and an email when a flow starts failing. Pro is $49 USD a month, twenty flows every hour, and an email on every failure. The free page check is a third thing again: one URL, once, looking at load, console, headers, and a few obvious leaks. It does not click. Use it before you trust a new deploy, then let the scheduled flow watch the click.