Spitfire

Not now and then, all the time: load testing that keeps watch without straining the system

In most teams load testing is a tool opened a few times a year, before a sale or a big release. Spitfire runs the same tests on production all the time at a low load: it keeps measuring that your flows work, have not drifted from their own normal and keep their SLO target, and it tells you once when something changes. Heavy load goes out only when you ask for it.

Always-on watchsample view
Watching6
Uptime (24 h)99.97%
Open incidents0
Last check12 s ago
Budget lowCheckout flownow 99.92% · target 99.9% · 20% left
Slower than normalOrder listp95 +25% (210 → 262 ms)
On target4 monitors keep their 30-day SLO.

Two modes, one test

You define the flow once: the sign-in token, the item added to the cart, the field the response must hold. The same test both keeps watch and, when needed, pushes the system; when the test changes, both follow.

1 · Watch

All the time, at a low load

Your critical flows are tried on production every 1–60 minutes with 1–10 virtual users, each scenario once. The system does not notice; you notice when something changes.

  • Uptime, step durations, recent failures
  • Living baseline: drift without thresholds
  • SLO and error budget
  • One notice per incident, drift and budget
2 · Heavy when needed

When you ask, the full load

Before a sale, a big release or an infrastructure change, the same test becomes a distributed load test: the load climbs step by step and you see the breaking point and what slowed down in the backend.

  • Breaking point and thresholds
  • Scheduled runs and a CI release gate
  • Version comparison (A/B)
  • Root cause with OpenTelemetry and monitoring alerts

What the watch does

An always-on watch on the dashboard

The card at the top of the main dashboard rolls up all your monitors: how many are watching, the last 24 hours' uptime, open incidents, the latest check; the ones that drifted from their normal and the ones whose error budget runs low, worst first. It refreshes every 5 seconds.

Living baseline and drift notices

Spitfire learns each monitor's normal by itself: it compares the last 24 hours' p95/p50 duration and error rate with the 7 days before. When a flow gets slower than its normal or fails more often, it is caught with no threshold set, and monitor.drift goes out once per drift: an "it is getting slower" warning before there is an outage.

SLO and error budget

Every monitor has a 30-day SLO target (99.9% by default). Spitfire shows the error budget left and how fast the last 24 hours spend it; monitor.budget goes out once when the budget falls to a quarter and once when it runs out.

One alert per incident

After N bad checks in a row, one monitor.down to your Slack, Teams, e-mail, SMS, webhook, Jira or ServiceNow channel, and one monitor.recovered when it is back. A single slow check wakes nobody. Channels: integrations.

Details, limits and setup: synthetic monitoring.

Heavy when needed

To see at which load a slowdown the watch found turns into a break, start the same test as a load test: the load climbs in stages and the run stops when a threshold breaks. Breakpoint testing, a release gate in CI/CD and version comparison are part of this mode. Scheduled runs do it every night or every week by themselves.

The watch stays in your network too

Checks leave from your runners and the results stay in your database; to watch an internal service you do not need to expose it to the internet. More: self-hosted load testing.

Frequently asked

Does always-on monitoring strain the live system?
No, that is the point. A monitor check runs every scenario once with 1–10 virtual users (60 s at most) and never overlaps the monitor's previous check; a check every 5 minutes weighs about as much as a few people browsing the site. Heavy load goes out only when you start a load test.
Do I have to set thresholds?
No. The living baseline learns each monitor's own normal from the last 7 days and tells you by itself when the last 24 hours are clearly slower or fail more often. If you like, you can also set duration thresholds per check and per step, and a 30-day SLO target.
Will I get a message for every slow check at night?
No. monitor.down goes out once per incident after N bad checks in a row, monitor.recovered once when it is back. A drift notice comes once per drift, a budget notice once when the budget falls to a quarter and once when it runs out; the drift and budget events are opt-in, ticked per channel.
Is it in the free edition?
Yes: the free edition has 1 monitor, checking every 15 minutes at most. More monitors and a check every minute come with the paid licenses; the limits are in the table on the synthetic monitoring page.

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

Installation guideGet a free key