Synthetic monitoring: do your user journeys still work on production?

Synthetic monitoring means trying the critical flows on a live system at regular intervals and measuring the result, without waiting for a real user to hit a problem: can people sign in, add to the cart, open the checkout page? In Spitfire, the test you wrote for load testing also runs as a synthetic monitor, with the same steps at a low load.

Why the same test rather than a separate tool

An endpoint answering 200 does not mean the flow works. Is the sign-in token taken and used in the next request, does the item added to the cart show up in it, does the response hold the expected field? Those are already your load test's steps, extractions and checks. Using the same test for monitoring means you do not define the flow twice; when the test changes, the monitor follows.

How it works

On a test, choose Run as synthetic monitor (or Testing → Synthetic monitoring).
Pick the interval (1, 5, 15 or 60 minutes), the number of VUs (1–10, default 1), one or more locations and the test's environment to use. Each location runs its own check on an idle runner there.
At each check every VU runs every scenario once (60 s at most), with the same runners, connections and license check as a run. A check never overlaps the monitor's previous one.
Checks run as the user who created the monitor, with that user's current rights; a monitor whose owner lost them turns off.

Dashboard: uptime, step durations, recent failures

Each monitor's dashboard shows uptime over 24 hours, 7 and 30 days, the per-step duration trend, the latest checks and failures with their error samples and the current state (up, down, slow, unknown), filtered by location. Checks are kept 30 days (on the free edition, the license's shorter retention: 7 days).

Example

Checkout flow · Istanbul · every 5 minutes · state: slow — in the last 3 checks the POST /checkout step was over the monitor's 800 ms step threshold (1.2 s, 1.4 s, 1.1 s).

Alerts: once per incident

After N bad checks in a row (failed, or slower than the monitor's check or step threshold) your existing notification channels (Slack, Teams, e-mail, SMS, webhook) get monitor.down once per incident, and monitor.recovered once when it is back. Disabled channels and channels paused by the license hear nothing. So one slow check does not wake anyone at night, and a real outage is not missed.

Limits by plan

The number of monitors and the shortest interval depend on the license (the limits come from the plan configuration):

Edition / plan	Monitors	Interval
Free	1	every 15 minutes at most
Project pass (30 days), Quarter (90 days), Growth monthly, Scale monthly	1	every 15 minutes at most
Growth yearly	10	as often as every minute
Scale yearly	30	as often as every minute
Enterprise yearly	unlimited	as often as every minute

Prices and plans: pricing and licenses.

The data stays in your network

Checks leave from your runners and results stay in your database. To monitor an internal service you do not need to expose it to the internet: a runner in that network is enough. More: self-hosted load testing.

Frequently asked

How is synthetic monitoring different from a load test?

It uses the same test with a different purpose. A load test pushes the system and records a run; a synthetic monitor runs every scenario once with 1–10 VUs and keeps only a compact result: passed, slow or failed, the step durations and one error sample.

Do checks count against the concurrent-run limit?

No. Synthetic monitor checks do not count against the concurrent-run limit and are not recorded as runs. When no runner is idle the check is skipped and counts for nothing.

Can I monitor a flow that changes data?

Yes, with an explicit confirmation. A test with data-changing steps (SQL/Mongo writes, risky Redis commands, HTTP requests that change data) must be confirmed on the monitor, because the monitor repeats them at every check against a live system. Without it the monitor is refused; if the test starts writing later, the monitor turns off.

Spitfire installs on Docker or Kubernetes with one command; every testing feature and protocol is open in the free edition.

Installation guide Get a free key