Where does your system break?

No. The controller, runners and results run on your own servers, and the license key is verified offline.

No. A test is built step by step in the web editor. If you prefer, write the same test as a JSON file and run it with the CLI.

Yes. In a WebSocket step every virtual user keeps one connection, like a browser tab: it sends a message, waits for the reply or for a message the server pushes (containing a given text), and the message goes to checks and extraction. The connection carries the cookies from login and reconnects on the next step if it drops; the handshake is measured as ws_connecting. An SSE step opens the event stream and reads until the given number of events (by type or content) arrived; the time to the first event is the sse_time_to_first_event metric. Both can have thresholds.

A runner whose connection drops and comes back within 10 seconds carries on; if it does not, the run stops, or continues without it if the test says so. If the controller is stopped (an update, a restart), it stops the active runs and stores their results first; if it goes down unexpectedly, the run closes as interrupted when it starts again. Either way the runners drop the load at once and webhook receivers get the end notice. Stop and thresholds work even while the database is slow; if some data could not be stored, the run says so as a warning.

Yes. "Shared iterations" splits a fixed number of iterations among the VUs; "per-VU iterations" has every VU run the same number. The test ends when the work is done, with a max duration as the ceiling. Across several runners the work is split exactly by each runner's share of the VUs. Good for data loading, smoke tests and one-off jobs.

No. Tests → Import API / HAR: give an OpenAPI 3, Swagger 2.0 or Postman v2.x collection, or a HAR recording (browser DevTools → Network → "Save all as HAR"), and pick requests. In a HAR, static files are dropped, tokens and ids become variables automatically, and cookies stay separate per virtual user. Only GET requests are taken by default; POST, PUT/PATCH and DELETE need a per-group approval plus the target host name, the approval is written to the audit log, and the test asks again on every run.

On the Integrations page, announce run start and end with a webhook and send live metrics over OTLP or Prometheus. With METI, "Connect to METI" is enough: symptoms that start on a tested host inside the test window are attributed to the load test by its root-cause analysis.

Yes. On the single sign-on page set up your OpenID Connect provider (Entra ID, Okta, Google, Keycloak…) or your LDAP / Active Directory. Accounts can open on first sign-in, or only accounts an admin created may enter; you can limit sign-in to groups, map admin groups to the admin role and sync memberships into Spitfire groups of the same name. Password sign-in can be left to admins only; LDAP passwords are never stored in Spitfire.

Yes. On the test's page, Schedule: pick a cron and time zone; the run starts with the rights of whoever created the schedule. Under Integrations → Notification channels add a Slack, Microsoft Teams or e-mail channel and turn on "Only notify on problems": you hear when a threshold breaks, a run fails, or a scheduled run does not start (no runners, missed). The e-mail carries the run's PDF report.

On the run page, Report → Download PDF or Share link. The link shows the HTML and PDF report without signing in; it lasts 1–90 days, can be revoked at any time, and every view is written to the audit log. Reports come in Turkish or English.

Create a token under profile menu → API tokens, add it to the pipeline as the SPITFIRE_TOKEN secret, and run spitfire cloud run "Test name" in a step. The CLI comes from the controller or the Docker image; the CI button on a test's page prepares GitHub Actions and GitLab CI steps. The step exits 0 (passed) or 99 (thresholds failed).

Docker or Kubernetes, on amd64 and arm64; Linux, macOS and Windows (Docker Desktop, one PowerShell command). A runner in a remote location can also run without Docker: with systemd on Linux, as a Windows service on Windows.

The code stays valid until the first admin exists and is stored: SPITFIRE_SETUP_CODE in ~/spitfire/deploy/docker/.env on Docker, the spitfire-secrets Secret on Kubernetes. The controller log also prints setup_code=, and re-running the installer shows the same code.

Yes. Save the certificate, the key and, if needed, the private CA to trust once under Connections → Client certificate (mTLS); HTTP, WebSocket and SSE steps pick it under "Client certificate". The key is stored encrypted and never enters the test definition; saving checks the certificate and key belong together, and the Test button checks the certificate has not expired.

You decide: the Data retention setting on the License page keeps per-second chart data, run logs and error samples (90 days by default), whole runs and the audit log for their own number of days; what you leave empty is kept forever. Tests' baseline runs are never deleted, and the page shows what would go before you save. The audit log is append-only: only entries older than 30 days are deleted this way, and the deletion is recorded too.

A 14-day grace period starts and the application says so. After it Spitfire keeps running within the free edition's limits; your tests, runs and reports are not deleted. Paste the new key on the License page and the limits open again at once, without reinstalling.

The application tells you about a new release itself (from a signature-checked release list), and security updates are marked. Updating is the same single install command: the database is backed up first and the settings kept; if anything goes wrong, --rollback returns to the previous release and its data. Runners installed without Docker update themselves from the Runners page or with auto-update.

Only scale: 100 virtual users, 500 requests/s, 30-minute runs, 2 runners, 1 location, 3 users and 30 days of results. Features are not restricted.