Question 1

Is my test data sent anywhere?

Accepted Answer

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

Question 2

Do I need to write code?

Accepted Answer

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.

Question 3

Can I bring my k6 or JMeter tests?

Accepted Answer

Yes. Tests → Open file turns a k6 script or a .jmx plan into a Spitfire test and opens it in the editor; the file is read, not run. Load model, requests, checks, values taken from responses, think times and thresholds are converted; what has no equivalent, like loops, conditions and custom metrics, is reported with its line. Details in the migration guide.

Question 4

How much load can my system take?

Accepted Answer

"Find the breaking point" in the Run dialog climbs one scenario's load in steps (say 10, 20, 30… iterations a second) and judges each step on its own numbers against the p95 and error rate you give. The first step that fails stops the run; the run page says "met the criteria at 200 iterations/s, not at 230". If the climb stopped because virtual users ran out, it also says that this is not the system's limit.

Question 5

Can I run the same test against staging and production?

Accepted Answer

Yes. On the test's Environments tab each environment gives its own address and variables and maps the steps' connections to its own (orders-db → orders-db-staging). You pick the environment when starting a run or a schedule and can scale the load (10% for a smoke test); the run shows which environment and scale it used. The test stays one test with one version history.

Question 6

Can I test live screens that use WebSocket or Server-Sent Events?

Accepted Answer

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. More: the WebSocket and SSE load testing guide.

Question 7

What if a runner or the controller drops during a run?

Accepted Answer

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.

Question 8

Can I run a fixed number of operations instead of a duration?

Accepted Answer

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.

Question 9

I have a Swagger document, a Postman collection or a browser recording. Do I write the test from scratch?

Accepted Answer

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. More: the OpenAPI and Postman guide.

Question 10

Our monitoring alarms during load tests. What can we do?

Accepted Answer

On the Integrations page, announce run start and end with a webhook and send live metrics over OTLP or Prometheus. Your monitoring can mark the test window from these events and tell symptoms during the test apart from real incidents.

Question 11

Can people sign in with their company account (Entra ID, Okta, Active Directory)?

Accepted Answer

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.

Question 12

Can a test run every night and tell us when something is wrong?

Accepted Answer

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, e-mail or SMS channel (SMS works with any SMS service's HTTP API or your own gateway) 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.

Question 13

How do I send results outside the team?

Accepted Answer

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.

Question 14

How do I run tests from my CI/CD pipeline?

Accepted Answer

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).

Question 15

Where can I install it?

Accepted Answer

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.

Question 16

I lost the setup code shown after installation. What now?

Accepted Answer

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.

Question 17

Our API wants a client certificate (mTLS); can I test it?

Accepted Answer

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.

Question 18

How long are results kept?

Accepted Answer

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. On the free edition per-second results are kept for at most 7 days.

Question 19

What happens when the license expires?

Accepted Answer

The yearly plans and the one-time month (and Project pass and Quarter licenses bought before) do not renew automatically; we remind you by e-mail 14 and 3 days before the end. When the license ends, a 14-day grace period starts and the application says so. On the monthly subscription the last key ends 4 days after the period end, and its grace is 1 day: an unpaid month returns to the free edition 5 days after the period end. After it Spitfire runs within the free edition's limits (1 user, 1 run at a time, 100 virtual users, 500 requests/s, 15-minute runs, 1 runner and 1 location, 7 days of results, 1 scheduled test, 1 notification channel and 1 synthetic monitor (at most every 15 minutes)); starting new runs needs a free key or a new license. Nothing is deleted: tests, runs and reports stay, extra users become read-only, extra schedules pause, the SSO settings are kept. Paste the new key on the License page and the limits open again at once, without reinstalling.

Question 20

How do I hear about new releases, and is updating hard?

Accepted Answer

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.

Question 21

How does the monthly subscription (Growth, Scale) work, and how do I cancel?

Accepted Answer

No commitment: you pay the first month by card and the subscription renews automatically every month from your card until you cancel. The limits are those of the plan's yearly edition (Growth or Scale); price lock, synthetic monitoring, PR comments and add-on packs come with the yearly plan. To cancel, use the “Cancel the subscription” link in any subscription e-mail or write to us: the subscription runs to the end of the period begun, then does not renew and nothing more is charged; the period begun is not refunded. To move to yearly, cancel the monthly one and buy the yearly plan.

Question 22

Is my card stored for the monthly subscription?

Accepted Answer

Your card is stored by the payment institution PayTR; we never see or store it. The first payment uses 3-D Secure; later months are charged to the same card at each period end. 3 days and 1 day before every renewal we e-mail you the amount and the date the card will be charged. If a charge fails we tell you and retry 1, 3 and 5 days later; if the last retry fails too, the subscription ends and Spitfire returns to the free edition's limits 5 days after the period end. Nothing is deleted.

Question 23

How do the monthly subscription's keys arrive?

Accepted Answer

Every month, a few minutes after the payment, a new key arrives by e-mail; paste it on the License page in Spitfire. Each key is valid until 4 days after the end of the period it was paid for, so there is time to paste the next one. Growth monthly keys need Spitfire 0.13.1 or later, Scale monthly keys 0.16.0 or later; the key is still verified offline.

Question 24

When does the license term start?

Accepted Answer

For the yearly plans and the one-time month, the day you first enter the key on Spitfire's License page (on the monthly subscription each key starts the day it is issued). Install a week after you got the key and you still lose no days; just enter it within 30 days of it being issued. The License page shows the activation date, the end and the days left; the key is still verified offline.

Question 25

What happens to what I paid when I upgrade?

Accepted Answer

It is taken off. Paste your key under “Upgrade my license” on the buy page: upgrade a Project pass or a one-time month within 30 days of issue and all you paid comes off; for the Quarter, Growth and Scale yearly, the value of the days left does (Growth to Scale too). It shows as its own line on the invoice. Days left are rounded up in your favour; the credit never exceeds the new plan's price and nothing is refunded. The new key replaces the old one.

Question 26

Does the price change when I renew?

Accepted Answer

Growth, Scale and Enterprise yearly have a price lock: renew with your current key within the last 30 days before the end and the new year costs what your original order paid (or the list price, if it went down). The lock covers one period. The new period starts the day after the current one ends, so renewing early loses no days.

Question 27

What is the price lock? What else comes with yearly?

Accepted Answer

Price lock: renew your yearly license with your current key in the last 30 days before the end and the new year costs what you first paid, or the list price if it went down. If you bought Growth yearly today for $1,900 incl. taxes, you pay $1,900 incl. taxes again when you renew on time, even if the list price has gone up. The lock covers one period; a license bought as a renewal renews at the current price next time. Synthetic monitoring: your scenario runs on production at low load every 1–60 minutes and tells Slack, Teams, SMS or e-mail when it breaks or slows down; yearly gives 10 monitors on Growth and 30 on Scale, other plans 1. PR comments: the CI run is compared with the baseline run and posted as a pull/merge request comment; a breached per-endpoint performance budget fails the pipeline. Add-on packs: raise the limits without changing plan: +5 users ($279 / year), +2,000 virtual users (+10,000 requests/s) ($499 / year), +4 hours of run length ($199 / year), +5 runners · +2 locations ($339 / year).

Question 28

If Growth's limits are not enough, must I move to Enterprise?

Accepted Answer

Not necessarily. Growth and Scale yearly take add-on packs: +5 users ($279 / year), +2,000 virtual users (+10,000 requests/s) ($499 / year), +4 hours of run length ($199 / year), +5 runners · +2 locations ($339 / year); prices include taxes. Packs added to a running license are priced for the days left and come with a new key. If Growth with packs comes near the Scale price and fits within Scale's limits, the buy page suggests Scale; if it does not fit, or Scale with packs reaches Enterprise level, it suggests Enterprise.

Question 29

Can we pay by bank transfer or get a quote?

Accepted Answer

Growth and Scale are bought by card; bank transfer and proforma are not taken on the buy page at the moment. If your organisation pays only by transfer, write to us. Enterprise is sold by quote: quote form; 1 production + 1 test installation, support by e-mail weekdays 09:00–18:00 (Istanbul time); 1 business day is the time to a first response, not to a fix.

Question 30

Which plan fits me?

Accepted Answer

For one testing period (before a launch or a campaign), the monthly subscription or the one-time month; for continuous testing (CI, nightly runs), yearly: it costs less a month, and only the yearly plan has price lock, synthetic monitoring, PR comments, add-on packs. All three have the plan's same limits. Growth: 5 users, 1 run at a time; per run 2,000 virtual users, 10,000 requests/s, 4-hour runs, 10 runners and 3 locations; e-mail support, answered within 2 business days. For several teams, several runs at once or more load, Scale: 15 users, 3 concurrent runs; per run 10,000 virtual users, 50,000 requests/s, 8-hour runs, 30 runners and 6 locations; e-mail support, answered within 1 business day. If you need more than that, unlimited concurrent runs or priority support, Enterprise yearly has no limits, by quote. On the yearly and one-time monthly plans the payment is taken once and the license does not renew itself. The monthly subscription renews automatically every month from your card; you cancel whenever you like. Every testing feature and protocol is open in every edition. Team and organisation features (SSO, audit log, multiple runners) are in the paid plans.

Question 31

What is the difference between the monthly subscription and the one-time month?

Accepted Answer

The product and the limits are the same. The subscription renews automatically every month from your card and you cancel whenever you like. With the one-time payment your card is not stored and the license does not renew itself when it ends. They cost the same.

Question 32

What does the free edition limit?

Accepted Answer

Scale and team features: 1 user, 1 run at a time, 100 virtual users, 500 requests/s, 15-minute runs, 1 runner and 1 location, 7 days of results, 1 scheduled test, 1 notification channel and 1 synthetic monitor (at most every 15 minutes). SSO / LDAP, the audit log and multiple runners are in the paid plans; PDF and shared reports say "Made with Spitfire Free". Every testing feature, all protocols and CI pass/fail are open. 14 days after installing, new runs need a free key: you get it by e-mail, it does not expire and is verified offline. Your tests and results never leave your servers; the only request Spitfire makes on its own is a daily version check that sends just its version number and can be turned off.

Question 33

How do I know whether the new release is slower than the old one?

Accepted Answer

With a comparison run. Pick the environment running the old release as A and the one running the new release as B. Spitfire runs the same test against both at the same time, and every runner splits its load evenly between them. The result shows the difference and the verdict for every step: better, no difference, or worse. Version comparison →

Question 34

My two environments are not identical. Can I still trust the result?

Accepted Answer

Before it starts, Spitfire compares the two environments and warns about the differences it sees. To measure how the environments differ on their own, run a calibration with the same release on both; later comparisons show that difference apart from the result.

Question 35

Why not run twice and compare the two runs?

Accepted Answer

Between two runs at different times the network, the caches and the load on shared infrastructure can change. Running both at once spreads those outside effects evenly over the two sides; what is left is the difference the release makes.

Question 36

I have one test environment. Can I still use it?

Accepted Answer

Yes. In sequential mode the two releases take turns on the same environment (A, B, A, B); each time you switch the release, Spitfire moves on to the next round.

Question 37

Can CI stop the deployment when the new release is slower?

Accepted Answer

Yes. Give spitfire cloud run the --compare flag; if the new release is worse the step exits with 98 and the deployment stops.

Feature	Spitfire
To write a test	Web editor or JSON
Single sign-on (OIDC, SAML, LDAP)	✓ group → role mapping
Self-hosted team UI	✓ roles, groups
SQL · Kafka · MQTT · Redis · MongoDB	✓ built in
Several locations in one run	✓ by percent
Tests from OpenAPI / Postman / HAR	✓ in the UI, auto-correlation
Capacity (breaking point) test	✓ stepped, states the capacity
Findings from a run	✓ with its numbers, conservative
Production write guard	✓
Shareable report	✓ PDF, HTML, link
Scheduled runs + Slack / Teams / e-mail	✓ built in, PDF attached
Alert on a regression against the baseline	✓ Slack, Teams, e-mail, SMS, webhook
Responses of failed requests	✓ samples on the run page
Two releases compared at the same time	✓ with a verdict and confidence intervals
Audit log	✓ tamper-proof
Pass/fail exit code for CI	✓ k6-compatible, on your runners

Where does your system break?Self-hosted, on-premise load testing and performance testing

Fill in a test like a form.

What's new in the recent releases?

From test to verdict.

Is the new release slower? Find out before it goes live.

Like for like

Takes out the environment difference

Release gate

What can it do?

Beyond HTTP, in the same test

One run, several cities.

What is in Spitfire?

Works by your organization's rules.

Data stays in your network

Runners dial out

Production write guard

Append-only audit log

Encrypted secrets

Database access by consent, least privilege

Single sign-on

Roles and groups

Audit log

Kubernetes or Docker

Multiple locations

The run in your pocket

Your first test in three steps.

Install

Create the admin

Add a test, press Run

From load to verdict, in one place.

Real user journeys

Tests from your API docs, a browser recording, or k6/JMeter

Realistic data and sessions

Load from several cities

Capacity and findings

Built-in OpenTelemetry: closer to the root cause

Scheduled runs, instant news

Sign in with the company identity

A guard against production writes

Live results, compared with history

Old release or new?

Not just "500": what the server said

Every save is a version

APIs that want a client certificate

A report ready for your manager or customer

A release gate in CI

Synthetic monitoring

Performance diff on every PR

Mock services and Turkish test data

Talks to your monitoring

Built for teams

What does a month of load testing cost?

Start free

Free

Growth

Scale

Enterprise

Frequently asked