<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title>Spitfire: releases and guides</title>
  <link>https://usespitfire.com/</link>
  <atom:link href="https://usespitfire.com/feed.xml" rel="self" type="application/rss+xml"/>
  <description>New releases, guides and articles from the Spitfire load testing platform.</description>
  <language>en-US</language>
  <lastBuildDate>Thu, 15 Oct 2026 12:00:00 GMT</lastBuildDate>
  <item>
    <title>Release 0.36.0</title>
    <link>https://usespitfire.com/release-notes#v0.36.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.36.0</guid>
    <pubDate>Thu, 15 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;New template "Sale-day rehearsal": the list → detail flow at 1×, 2×, 3× and 5× your normal peak, 2 minutes per stage. It stops when p95 passes 800 ms or the error rate 2%, or when the system has slowed so far the target rate can't be sent; the report shows how many times normal traffic you can take on sale day.&lt;/li&gt;&lt;li&gt;Report and run page: the stop reason in the report's language.&lt;/li&gt;&lt;li&gt;Demo target (--demo): /limited/items, holding up to ~230 requests per second, to try the rehearsal right after installing.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Coordinated omission: why a load test wrongly says "passed"</title>
    <link>https://usespitfire.com/guides/coordinated-omission</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/coordinated-omission</guid>
    <pubDate>Thu, 15 Oct 2026 08:48:04 GMT</pubDate>
    <description>Coordinated omission and the VU ceiling: a slow system lowers its own load and hides latency. Open models, the dropped iterations threshold and a real run.</description>
  </item>
  <item>
    <title>Black Friday load testing: get ready for the sale</title>
    <link>https://usespitfire.com/black-friday-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/black-friday-load-testing</guid>
    <pubDate>Thu, 15 Oct 2026 08:30:14 GMT</pubDate>
    <description>Black Friday load testing: measure how many times your normal traffic you can take. A three-week plan, a checklist and a ready sale-day rehearsal template.</description>
  </item>
  <item>
    <title>Sample load test report: look before you install</title>
    <link>https://usespitfire.com/sample-report</link>
    <guid isPermaLink="true">https://usespitfire.com/sample-report</guid>
    <pubDate>Thu, 15 Oct 2026 08:30:14 GMT</pubDate>
    <description>A real sale-day rehearsal run's Spitfire report: stages, p95, error rate, step results and findings. Open the HTML or download the PDF.</description>
  </item>
  <item>
    <title>Release 0.35.3</title>
    <link>https://usespitfire.com/release-notes#v0.35.3</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.35.3</guid>
    <pubDate>Wed, 14 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;First steps: a new page really opens at its top; a test made from a template opens with Run in view (the 0.35.2 fix was cut short by the browser's smooth scrolling).&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.35.2</title>
    <link>https://usespitfire.com/release-notes#v0.35.2</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.35.2</guid>
    <pubDate>Wed, 14 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;Report: a Kafka topic the broker does not know gets its own finding ("Topic not found", with the command to create it) instead of showing only in the failed request samples.&lt;/li&gt;&lt;li&gt;Report: "Slowest step" leaves out steps that wait for a message (Kafka consume, MQTT/NATS subscribe, AMQP consume, SQS/WebSocket receive); "What we saw" also reports latency thresholds set on steps.&lt;/li&gt;&lt;li&gt;Kafka template: the consumer waits 30 s per record, so the consumer group's warm-up on the first run no longer shows up as timeouts.&lt;/li&gt;&lt;li&gt;First steps: with no tests yet, "New test" and the empty dashboard lead to the template gallery; a new page opens at its top (Run is in view on a test made from a template); the template form scrolls into view.&lt;/li&gt;&lt;li&gt;Connections: the name example follows the connection type; the table fits at 1280 px.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.35.1</title>
    <link>https://usespitfire.com/release-notes#v0.35.1</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.35.1</guid>
    <pubDate>Wed, 14 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;The Windows installer (install.ps1, uninstall.ps1) also speaks English or Turkish, by the Windows display language; $env:SPITFIRE_LANG = 'en' | 'tr' picks one. Turkish characters no longer come out garbled in Windows PowerShell 5.1.&lt;/li&gt;&lt;li&gt;Suggest from schema: in a schema of up to 20 tables the tables start selected.&lt;/li&gt;&lt;li&gt;Test editor: a step name the editor gave ("Home page") becomes the new protocol's name when the protocol changes; under a URL starting with {{base}} a line says where the variable is set; the error band clears sooner once the error is fixed.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.35.0</title>
    <link>https://usespitfire.com/release-notes#v0.35.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.35.0</guid>
    <pubDate>Wed, 14 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;New test from a template: HTTP steady load, breaking point, list → detail, Kafka, MQTT, SQL, PostgreSQL query mix and OCPP 1.6J chargers; fill in a few fields and save. Templates ship inside the product and work in offline installs too.&lt;/li&gt;&lt;li&gt;The empty test list and the dashboard suggest the template gallery for a first test.&lt;/li&gt;&lt;li&gt;Demo target: install.sh docker --demo (Windows: install.ps1 -Demo) adds a small target service next to the install; the HTTP and OCPP templates open pointed at it, and changing the address moves them to your own system. --no-demo removes it.&lt;/li&gt;&lt;li&gt;A three-line "What we saw" summary on top of the run report: p95 and the latency threshold, error rate, breaking point or the most important finding; clicking a line jumps to its section.&lt;/li&gt;&lt;li&gt;New finding: slow query (a query clearly slower than the others in an SQL mix or across SQL steps).&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.34.1</title>
    <link>https://usespitfire.com/release-notes#v0.34.1</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.34.1</guid>
    <pubDate>Wed, 14 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;The install scripts (install.sh, uninstall.sh, spitfire.sh) speak English or Turkish by the locale; SPITFIRE_LANG=en|tr picks one.&lt;/li&gt;&lt;li&gt;A newly created test shows its Run button without reloading the page.&lt;/li&gt;&lt;li&gt;When the license's requests-per-second cap held a run back, the report says so as a finding.&lt;/li&gt;&lt;li&gt;Test editor: Create a connection opens the connection dialog in place, with the step's type picked; when exactly one connection fits the protocol it is picked.&lt;/li&gt;&lt;li&gt;Try it and the Connections page: a refused connection to localhost suggests host.docker.internal; a missing Kafka topic gets a hint; a connection test's whole error is shown.&lt;/li&gt;&lt;li&gt;Connections: Suggest from schema stays visible on narrow screens; editing a connection clears its old test result.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.34.0</title>
    <link>https://usespitfire.com/release-notes#v0.34.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.34.0</guid>
    <pubDate>Wed, 14 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;Monitoring events: the problems your monitoring system opens during a run are placed on the load stages and the breaking point. The run report shows what opened on which host at which stage, and the one closest to the breaking point. One module, two connections: Zabbix and Datadog.&lt;/li&gt;&lt;li&gt;Zabbix connection (Zabbix 5.4 and later): the problems opened in the run's window are read with their host, severity and tags, filtered by host group, host and minimum severity. A read-only API token is enough; nothing is written to Zabbix.&lt;/li&gt;&lt;li&gt;Datadog connection: the monitors that alerted in the run's window and their recoveries are read with their host, status, priority and tags; every Datadog site and a proxy in front of the API are supported. An Application key with two read scopes is enough; nothing is written to Datadog.&lt;/li&gt;&lt;li&gt;License: monitoring events come with Enterprise; on every other edition, the free one included, they are an add-on module carried by the key. Each installation can try it once for 7 days; when the trial ends the connections are kept, and what was read for past runs stays on those runs.&lt;/li&gt;&lt;li&gt;Docs: Zabbix and Datadog in the Observability chapter, the add-on module and its trial in the License chapter.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Free 30-day pilot with your first test ready</title>
    <link>https://usespitfire.com/pilot</link>
    <guid isPermaLink="true">https://usespitfire.com/pilot</guid>
    <pubDate>Mon, 12 Oct 2026 12:55:09 GMT</pubDate>
    <description>The first 5 teams get a free 30-day Scale license, a starter test and e-mail support. Load test Kafka, MQTT, SQL, gRPC and HTTP on your own servers, no scripts.</description>
  </item>
  <item>
    <title>Release 0.33.0</title>
    <link>https://usespitfire.com/release-notes#v0.33.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.33.0</guid>
    <pubDate>Mon, 12 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;Installing and updating without internet: every release publishes one signed bundle per platform (`spitfire-offline-&amp;lt;version&amp;gt;-linux-amd64|arm64.tar.gz`) with the Spitfire and Postgres images, the installer files, the Helm chart and the signed release list; a first installation works from the bundle alone. The bundles are listed at usespitfire.com/install.&lt;/li&gt;&lt;li&gt;`install.sh docker|kubernetes|runner --offline &amp;lt;bundle&amp;gt;` checks the bundle's signature without going online (OpenSSL 3) and loads the images with `docker load`; on Kubernetes they are pushed to your registry with `--registry`. If the signature does not match, nothing is touched.&lt;/li&gt;&lt;li&gt;`--postgres-image` uses the Postgres image from an internal registry mirror; it is kept across updates.&lt;/li&gt;&lt;li&gt;When the controller cannot check for updates (turned off or no internet) and the running release is over 60 days old, admins see a calm reminder with the release's age and how to update offline.&lt;/li&gt;&lt;li&gt;Docs: "Updating without internet" in the Install chapter (update with temporary internet access, an internal registry mirror, the offline bundle).&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.32.2</title>
    <link>https://usespitfire.com/release-notes#v0.32.2</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.32.2</guid>
    <pubDate>Mon, 12 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;The Docker image is now `usespitfire/spitfire`. Install and update commands, the Helm chart and the docs use the new name; `docker pull usespitfire/spitfire:latest`.&lt;/li&gt;&lt;li&gt;Buy, free key and account links in the product go to usespitfire.com in English.&lt;/li&gt;&lt;li&gt;Links to the example tests and the GitHub Action point at the github.com/usespitfire organization.&lt;/li&gt;&lt;li&gt;Browser card: INP is shown only for steps that click or type. Highlighted table rows have proper tints in the dark theme.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.32.1</title>
    <link>https://usespitfire.com/release-notes#v0.32.1</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.32.1</guid>
    <pubDate>Mon, 12 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;English links in the product go to usespitfire.com; install and update commands use the short address: `curl -fsSL https://spitfire.sh | bash` / `irm https://spitfire.sh/ps | iex`. For firewalls that allow only spitfire.tr, the long form (`spitfire.tr/install.sh`) is in the docs.&lt;/li&gt;&lt;li&gt;Helm repository: `helm repo add spitfire https://spitfire.sh/helm` (the old spitfire.tr/download/helm address keeps working).&lt;/li&gt;&lt;li&gt;Docs: screenshots of the Backend tab's Where the time went and the trace waterfall.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Web Vitals under load: LCP, CLS and INP with real browsers</title>
    <link>https://usespitfire.com/guides/web-vitals-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/web-vitals-load-testing</guid>
    <pubDate>Sat, 10 Oct 2026 20:37:48 GMT</pubDate>
    <description>Core Web Vitals during a load test with real browsers: LCP, CLS, INP, TTFB; user journeys, browser runners, measurement reliability and thresholds.</description>
  </item>
  <item>
    <title>GraphQL load testing: per-operation latency, errors, mutations</title>
    <link>https://usespitfire.com/guides/graphql-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/graphql-load-testing</guid>
    <pubDate>Sat, 10 Oct 2026 20:37:48 GMT</pubDate>
    <description>GraphQL load testing: per-operation latency and errors, errors inside HTTP 200, query depth, generating tests from introspection and approving mutations.</description>
  </item>
  <item>
    <title>NATS and AWS SQS/SNS load testing: acks and end-to-end latency</title>
    <link>https://usespitfire.com/guides/nats-sqs-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/nats-sqs-load-testing</guid>
    <pubDate>Sat, 10 Oct 2026 20:37:48 GMT</pubDate>
    <description>NATS (core and JetStream) and AWS SQS/SNS load testing: publish acks, request-reply, pull consumers, long polling, end-to-end latency and cost traps.</description>
  </item>
  <item>
    <title>Release 0.32.0</title>
    <link>https://usespitfire.com/release-notes#v0.32.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.32.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;Trace drill-down on the Backend tab: click a test request's trace id to open its spans as a waterfall (service, operation, duration, error, database statement). Spans come from Spitfire's OTLP receiver, otherwise from the run's Tempo or Jaeger connection; when the trace is not found, it says so.&lt;/li&gt;&lt;li&gt;Where the time went: from the test requests' traces, each load stage shows which service and database the time was spent in (span self time) as a share; the request's time outside the trace (network, load balancer) is its own row. The breaking point finding names the component whose share grew most, with the measured values (e.g. orders-db 12% → 71%). Shares are computed from the sampled (slowest and failed) requests.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.31.0</title>
    <link>https://usespitfire.com/release-notes#v0.31.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.31.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;Browser step: next to the protocol load, a few real browser (headless Chromium) VUs take a user journey (open the page, click, type, wait, check the text) and measure what the user sees: LCP, CLS, INP, TTFB and load time. The Browser card on the run page colours them with Google's thresholds and says when a busy runner (browser_lag) makes them unreliable.&lt;/li&gt;&lt;li&gt;New image usespitfire/spitfire:&amp;lt;version&amp;gt;-browser: runners with Chromium label themselves browser, and runs with browser steps go only to them. The Runners page offers this image when adding a runner. License: browser VUs per run, free 1, Growth 5, Scale 20, Enterprise unlimited.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.30.0</title>
    <link>https://usespitfire.com/release-notes#v0.30.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.30.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;Performance budgets and PR/MR comments on the free edition: licenses without these features (the free edition, Project pass, Quarter, monthly subscriptions) save budgets on 1 test and --pr-comment works on 1 repository. The repository is registered by the first comment; an installation admin resets it on the License page. No limit on the yearly plans and Enterprise. This needs the 0.30.0 CLI too; older CLIs still skip the comment on the free edition.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.29.0</title>
    <link>https://usespitfire.com/release-notes#v0.29.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.29.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;The way to upgrade: limit messages open the right part of the buy page (add-on packs for users, virtual users and requests/s on a paid key, the upgrade for the other limits, the plans on the free edition). On the License page an installation admin opens the buy page with the key through Upgrade the plan, Buy add-on packs and Renew: the page fills in the key and credits the time left. The limit hit and the key travel after the address's #, which goes to no server; Spitfire sends nothing anywhere.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.28.0</title>
    <link>https://usespitfire.com/release-notes#v0.28.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.28.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;Streaming the audit log to a SIEM (Enterprise): Audit log → Streaming to a SIEM. Syslog (RFC 5424; TLS, TCP or UDP) or a signed webhook (X-Spitfire-Signature). Entries go as they are recorded, in order and at least once; when the target cannot be reached it retries from where it stopped, and nothing is lost on a controller restart. Every event is hash-chained to the previous one, so the receiver can verify that nothing was left out or changed. The audit table stays append-only.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.27.0</title>
    <link>https://usespitfire.com/release-notes#v0.27.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.27.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;SCIM 2.0 provisioning (Enterprise): Okta, Entra ID and other identity providers create, update and deactivate users and manage group memberships (Single sign-on page → SCIM). A deactivated user's sessions, mobile sign-in and API tokens stop working at once. New users are created with the chosen SSO method in the chosen workspace; a deleted account stays disabled with its tests and audit trail. The last enabled admin cannot be deactivated; every change is audited.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.26.0</title>
    <link>https://usespitfire.com/release-notes#v0.26.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.26.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;HTTP/3 (QUIC): pick it as the HTTP version in the test options; HTTP and GraphQL steps go over QUIC (for CDNs and servers with HTTP/3 on). Timings are the same; the QUIC handshake shows as both connecting and TLS time. No fallback to HTTP/2.&lt;/li&gt;&lt;li&gt;MQTT 5: with version 5 on an MQTT connection, publishes and requests get user properties, content type and message expiry; an incoming message's user properties reach checks and extractors as headers. Request/reply matches by correlation data: only the request's own reply is accepted, late replies to earlier requests are not. 3.1.1 stays the default.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.25.0</title>
    <link>https://usespitfire.com/release-notes#v0.25.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.25.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;AWS SQS / SNS step: send to a queue (FIFO group and deduplication IDs, delay, message attributes), receive with long polling and delete (or keep), and publish to an SNS topic. Sent messages are stamped; receive steps measure sqs_e2e_latency for the same runner's messages.&lt;/li&gt;&lt;li&gt;AWS connection type: region and an access key (stored encrypted) or the machine's own credentials (environment, profile, IAM role; only an installation admin can turn this on); a custom endpoint for LocalStack, ElasticMQ or a VPC endpoint.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.24.0</title>
    <link>https://usespitfire.com/release-notes#v0.24.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.24.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;NATS step: core publish, subscribe (shared with a queue group) and request/reply; publish to JetStream (measured to the stream's ack) and consume from a pull consumer (a durable consumer shared by the runner's VUs, created to start from new messages when missing). Publishes are stamped: steps that wait for messages or consume from JetStream measure nats_e2e_latency for the same runner's messages (as with Kafka).&lt;/li&gt;&lt;li&gt;NATS connection type: servers; user/password, token, NKey seed or a .creds file (stored encrypted); TLS; shared connections per runner or one per VU; JetStream domain.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Release 0.23.0</title>
    <link>https://usespitfire.com/release-notes#v0.23.0</link>
    <guid isPermaLink="true">https://usespitfire.com/release-notes#v0.23.0</guid>
    <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
    <description>&lt;ul&gt;&lt;li&gt;GraphQL step: a POST with the query, variables (JSON, templates allowed) and operation name. A response with errors fails the step even with HTTP 200, and the first error message shows in the error samples (can be turned off for expected partial results). "Load schema" lists the root fields with introspection and fills in the query and example variables for the field you pick. Steps with a mutation need the write confirmation; subscriptions are not supported.&lt;/li&gt;&lt;li&gt;The API import reads GraphQL: give the endpoint as the address (read with introspection) or upload an introspection result; every query and mutation you pick becomes a GraphQL step, and mutations ask for confirmation as operations that change data.&lt;/li&gt;&lt;/ul&gt;</description>
  </item>
  <item>
    <title>Load testing without scripting: journeys, variables, checks</title>
    <link>https://usespitfire.com/guides/load-testing-without-scripting</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/load-testing-without-scripting</guid>
    <pubDate>Tue, 06 Oct 2026 20:12:44 GMT</pubDate>
    <description>Load testing without writing scripts: user journeys, values from responses, CSV test data, checks, load models and thresholds in a form; what needs code.</description>
  </item>
  <item>
    <title>MQTT load testing: devices, connections, QoS and latency</title>
    <link>https://usespitfire.com/guides/mqtt-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/mqtt-load-testing</guid>
    <pubDate>Tue, 06 Oct 2026 20:12:44 GMT</pubDate>
    <description>MQTT broker load testing: concurrent device connections, reconnect storms, publish latency at QoS 0, 1 and 2, subscriptions and client id pitfalls.</description>
  </item>
  <item>
    <title>RabbitMQ load testing: confirms, consumers and queue depth</title>
    <link>https://usespitfire.com/guides/rabbitmq-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/rabbitmq-load-testing</guid>
    <pubDate>Tue, 06 Oct 2026 20:12:44 GMT</pubDate>
    <description>RabbitMQ (AMQP) load testing: publisher confirm latency, consumer throughput, prefetch and acks, queue depth, flow control and common mistakes.</description>
  </item>
  <item>
    <title>Redis load testing: command latency, pools and hot keys</title>
    <link>https://usespitfire.com/guides/redis-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/redis-load-testing</guid>
    <pubDate>Tue, 06 Oct 2026 20:12:44 GMT</pubDate>
    <description>Redis load testing: p99 command latency, throughput, connection pools, hot keys, memory and eviction; cluster and sentinel, dangerous commands.</description>
  </item>
  <item>
    <title>Database load testing: PostgreSQL, MySQL, SQL Server, Oracle</title>
    <link>https://usespitfire.com/guides/database-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/database-load-testing</guid>
    <pubDate>Tue, 06 Oct 2026 20:12:44 GMT</pubDate>
    <description>Database load testing for PostgreSQL, MySQL, SQL Server and Oracle: latency, connections, locks, consented query suggestions from the schema, SSH tunnels.</description>
  </item>
  <item>
    <title>Distributed load testing on Kubernetes: runners, locations</title>
    <link>https://usespitfire.com/guides/distributed-load-testing-kubernetes</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/distributed-load-testing-kubernetes</guid>
    <pubDate>Tue, 06 Oct 2026 20:12:44 GMT</pubDate>
    <description>Distributed load testing on Kubernetes: splitting load across runner pods, pods per run, merging percentiles correctly and load from several locations.</description>
  </item>
  <item>
    <title>Creating load tests from Swagger/OpenAPI and Postman</title>
    <link>https://usespitfire.com/guides/load-test-from-openapi-postman</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/load-test-from-openapi-postman</guid>
    <pubDate>Mon, 05 Oct 2026 11:07:15 GMT</pubDate>
    <description>Load tests from a Swagger/OpenAPI document or a Postman collection: what is generated, what you still edit by hand, and how to set variables and environments.</description>
  </item>
  <item>
    <title>WebSocket and SSE load testing: connections, messages, latency</title>
    <link>https://usespitfire.com/guides/websocket-sse-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/websocket-sse-load-testing</guid>
    <pubDate>Mon, 05 Oct 2026 11:04:51 GMT</pubDate>
    <description>WebSocket and Server-Sent Events load testing: concurrent connections, handshake time, message and first-event latency, proxy timeouts and reconnect storms.</description>
  </item>
  <item>
    <title>gRPC load testing: unary and streaming calls, HTTP/2 connections</title>
    <link>https://usespitfire.com/guides/grpc-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/grpc-load-testing</guid>
    <pubDate>Mon, 05 Oct 2026 11:02:48 GMT</pubDate>
    <description>gRPC load testing: unary and streaming calls, time to first message and per-message latency, HTTP/2 connections and the load balancer trap, deadlines.</description>
  </item>
  <item>
    <title>Kafka load testing: throughput, end-to-end latency and lag</title>
    <link>https://usespitfire.com/guides/kafka-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/kafka-load-testing</guid>
    <pubDate>Mon, 05 Oct 2026 11:00:42 GMT</pubDate>
    <description>Kafka load testing: producer and consumer load, throughput, end-to-end latency, the lag of the test's and your real service's consumer groups; acks pitfalls.</description>
  </item>
  <item>
    <title>Performance testing in CI/CD: a load test gate in the pipeline</title>
    <link>https://usespitfire.com/guides/performance-testing-in-ci-cd</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/performance-testing-in-ci-cd</guid>
    <pubDate>Mon, 05 Oct 2026 08:27:18 GMT</pubDate>
    <description>Performance testing in CI/CD: where in the pipeline, how much load, how to handle noise; spitfire cloud run, its exit codes and a pull request comment.</description>
  </item>
  <item>
    <title>Breakpoint testing: finding your system's capacity</title>
    <link>https://usespitfire.com/guides/breakpoint-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/breakpoint-testing</guid>
    <pubDate>Mon, 05 Oct 2026 08:25:23 GMT</pubDate>
    <description>Breakpoint testing: climb the load in steps to find the rate where your system misses its p95 and error-rate criteria, then take it into capacity planning.</description>
  </item>
  <item>
    <title>What is p95? p95, p99 and latency percentiles explained</title>
    <link>https://usespitfire.com/guides/p95-p99-latency-percentiles</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/p95-p99-latency-percentiles</guid>
    <pubDate>Mon, 05 Oct 2026 08:22:53 GMT</pubDate>
    <description>What p95 means, what p99 shows and why average latency misleads: a practical guide to reading percentiles and writing performance test thresholds.</description>
  </item>
  <item>
    <title>Load, stress, spike and soak testing: the differences</title>
    <link>https://usespitfire.com/guides/load-stress-spike-soak-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/guides/load-stress-spike-soak-testing</guid>
    <pubDate>Mon, 05 Oct 2026 08:20:56 GMT</pubDate>
    <description>What load, stress, spike and soak tests measure, how to shape the load and how long to run each: a practical guide to the types of performance testing.</description>
  </item>
  <item>
    <title>OpenTelemetry in load testing: closer to the root cause</title>
    <link>https://usespitfire.com/opentelemetry-root-cause</link>
    <guid isPermaLink="true">https://usespitfire.com/opentelemetry-root-cause</guid>
    <pubDate>Mon, 05 Oct 2026 08:18:17 GMT</pubDate>
    <description>OpenTelemetry in load testing: align traces, metrics and logs with the load stages, no agent. Tempo, Jaeger, Loki, Zabbix and Datadog alerts.</description>
  </item>
  <item>
    <title>Synthetic monitoring: test user journeys on production</title>
    <link>https://usespitfire.com/synthetic-monitoring</link>
    <guid isPermaLink="true">https://usespitfire.com/synthetic-monitoring</guid>
    <pubDate>Mon, 05 Oct 2026 08:18:17 GMT</pubDate>
    <description>Synthetic monitoring: your load test scenario runs on production every 1-60 minutes at low load; uptime, step durations, down and recovered alerts.</description>
  </item>
  <item>
    <title>Self-hosted load testing tool: your data stays in your network</title>
    <link>https://usespitfire.com/self-hosted-load-testing</link>
    <guid isPermaLink="true">https://usespitfire.com/self-hosted-load-testing</guid>
    <pubDate>Mon, 05 Oct 2026 08:14:49 GMT</pubDate>
    <description>Self-hosted (on-premise) load testing: controller, database and runners on your infrastructure; offline license, works air-gapped. Docker and Kubernetes.</description>
  </item>
</channel>
</rss>
