Spitfire 0.7.0 release notes
Released: 2026-10-03
- Synthetic monitoring: a test runs on production at low load every 1, 5, 15 or 60 minutes. Only a summary is kept (success, step durations, an error sample), not a full run. The monitoring dashboard shows uptime, step duration trends and the latest failures. Consecutive failures or a slow step send one alert to your notification channels, and a "recovered" message when it is back. Tests that change data need an explicit confirmation. The free edition has 1 monitor (at most every 15 minutes).
- Performance check per pull request: the test run in CI compares itself with the reference run and comments on the GitHub pull request or GitLab merge request (p95, p99 and error rate per step; the same comment is updated on every push). A breached per-step performance budget fails the run. The test page charts the p95 trend of recent runs by commit or version tag.
- Toward the root cause with OpenTelemetry: Spitfire installs no agent; it reads the system's own data. Your OTel Collector can export to Spitfire over OTLP, or Spitfire queries Prometheus, Tempo, Jaeger and Loki. Traces, metrics and logs of the run window are matched with the load stages; findings say only what the data shows. A new Backend tab on the run page. Adding a W3C traceparent to requests is a test setting (off by default).
- Mock services: test doubles of outside services such as payment, SMS and cargo, with configurable latency, error rate and templated responses. Templates for iyzico, PayTR, a generic SMS provider and a generic cargo API. They run inside the controller (SPITFIRE_MOCK_ADDR) or as a separate `spitfire mock`.
- Turkish test data: scenario variables such as {{fake.tckn}}, {{fake.iban}}, {{fake.phone}}, {{fake.fullName}}, {{fake.city}}, and "Generate data" on the Data files page for a CSV. The values pass the checks but belong to no real person or account.
- Agency workspaces: several client workspaces in one installation. Tests, connections, secrets, results, schedules, monitors and notification channels are isolated between them. Report branding per workspace (logo, company name, colour). Everything that exists moves to the Default workspace; a single-workspace installation looks the same. The number of workspaces comes with the license.
- Tests from real traffic: the endpoint mix and arrival rates are derived from access logs (nginx, ALB/ELB, CSV) or trace exports, and a test is generated. Logs are not stored; token, password and session-like values are removed while reading.
- Capacity estimate: from a breakpoint run, "about N instances for X concurrent users", written as an estimate with its assumptions.
- Fault injection under load (Kubernetes): delete selected pods or add network latency during a run and measure the recovery time. Off by default; an installation admin chooses the allowed namespaces, every run asks for confirmation again, and it is recorded in the audit log.
- Fixes: for tests with data-changing HTTP steps, the run dialog and the editor's try run did not show the confirmation, so such tests could not be started from the UI. The threshold that aborted a run did not reach the run page and the CLI (exit code 97).
Updating
Your installation tells you about a new release itself: admins see its notes and the update command for that installation at the top of the UI. The command backs up the database first and keeps the settings (Updating). You can also follow new releases with the RSS feed.