Flood.io Load Testing: Complete Guide

09 Oct 2026 — 6 min read

Load testing at scale means either managing your own infrastructure or paying someone else to do it. Flood.io is firmly in the second camp. You write the test scripts in tools you already know — JMeter, Gatling, or Puppeteer — and Flood handles spinning up hundreds of nodes, distributing load across regions, and aggregating the results. This guide covers how the platform works, what it's good at, and where it falls short.

What Flood.io Is

Flood.io is a cloud-based load testing platform that was acquired by Tricentis in 2021. The core value proposition hasn't changed since the acquisition: bring your own test scripts, Flood provides the infrastructure to run them at scale.

Before Flood, running a serious load test meant provisioning EC2 instances, installing JMeter or Gatling, configuring distributed mode, collecting logs from each node, and stitching together results. That's a half-day of work before you've even thought about your test scenarios. Flood eliminates that overhead.

The platform supports three script types:

JMeter (.jmx files) — the most common starting point for teams migrating from self-hosted
Gatling (Scala simulations) — better throughput per node, more code-driven
Flood Element — a proprietary tool built on Puppeteer for browser-level load testing

After the Tricentis acquisition, Flood also integrates with NeoLoad (Tricentis's enterprise load testing tool) and connects into the broader Tricentis testing platform.

Infrastructure Model

Understanding how Flood runs your tests matters for cost estimation and test design.

Floods, Grids, and Nodes

The terminology Flood uses:

Node — a single compute instance running your test script. One JMeter node might run 500 concurrent virtual users depending on your test design and available memory.

Grid — a collection of nodes that run together as a single load test. You define how many nodes, which regions, and what instance type.

Flood — a single load test execution. When you "launch a flood," you're telling Flood to spin up your grid, run your script, and collect results.

Node Types

Flood offers three ways to run nodes:

Flood Grid (managed) — Flood provisions and manages the infrastructure on its own cloud. This is the simplest option. You pick a region, specify node count, and Flood handles everything. The tradeoff is less control over instance types and network configuration.

On-demand nodes (AWS/GCP/Azure) — You connect your own cloud account to Flood, and nodes run in your VPC. This matters when your application is also in AWS and you need to test from inside the same network. You get more control, but setup is more involved — you need to configure IAM roles, VPC peering, or security group rules to let Flood nodes talk to your application.

On-premise agents — Flood agents installed on your own hardware or private cloud. Useful when your application can't be reached from the public internet, or when compliance requirements prevent using external cloud infrastructure.

Geographic Distribution

One of Flood's practical strengths is multi-region testing. You can split a flood across regions — for example, 40% of load from US-East, 30% from EU-West, 30% from APAC. This tests CDN behavior, region-specific latency, and failover logic in a way that single-region tests can't.

Configuration is straightforward: when launching a flood, you select multiple regions and specify node allocation per region. Results are aggregated into a single dashboard but can be filtered by region.

Supported Script Types in Detail

JMeter

JMeter is the most common path into Flood because most teams already have JMeter test plans. Upload your .jmx file, configure the node count, and run. Flood handles the distributed JMeter setup — you don't need to configure remote hosts or aggregate listeners manually.

One thing to know: Flood strips some JMeter elements that don't make sense in distributed mode (like certain listeners that write to local files). The results dashboard replaces these. If your test plan relies on local file output for something specific, you'll need to rework that logic.

JMeter properties and CSV data files can be uploaded alongside your .jmx. For parameterized tests using CSV data sets, Flood distributes the data across nodes automatically.

Gatling

Gatling simulations run as compiled Scala code. On Flood, you upload your simulation source file and Flood compiles and runs it. The advantage over JMeter is resource efficiency — Gatling's Akka-based architecture handles more concurrent users per node.

A basic Gatling simulation for Flood looks like any other Gatling simulation:

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

class BasicSimulation extends Simulation {
  val httpProtocol = http
    .baseUrl("https://your-app.example.com")
    .acceptHeader("application/json")

  val scn = scenario("API Load Test")
    .exec(
      http("Get homepage")
        .get("/")
        .check(status.is(200))
    )
    .pause(1)
    .exec(
      http("Get products")
        .get("/api/products")
        .check(status.is(200))
        .check(jsonPath("$.products").exists)
    )

  setUp(
    scn.inject(
      rampUsers(500).during(5.minutes),
      constantUsersPerSec(100).during(10.minutes)
    )
  ).protocols(httpProtocol)
}

Flood reads the users setting from its configuration rather than from the simulation's setUp block. If you're used to controlling load in the simulation itself, this is a behavioral difference to account for.

Flood Element

Flood Element is a different beast. Instead of virtual users making HTTP requests directly, Element runs headless Chromium browsers. Each "user" is a real browser session.

This has two implications:

Resource cost: browser instances consume far more memory and CPU than virtual HTTP users. A node that handles 500 JMeter users might only handle 10-20 Element users.
Realism: Element tests exercise your full frontend stack — JavaScript execution, AJAX requests, CSS rendering, third-party scripts. A JMeter test that hits your API directly won't catch a performance problem caused by a slow third-party analytics script. Element will.

Element scripts use a Puppeteer-like API:

import { step, TestSettings, Until, By } from '@flood/element'

export const settings: TestSettings = {
  loopCount: -1,
  description: 'Flood Element load test',
  screenshotOnFailure: true,
  waitTimeout: 30,
}

export default async function() {
  step('Navigate to homepage', async browser => {
    await browser.visit('https://your-app.example.com')
    await browser.wait(Until.pageLoaded())
  })

  step('Search for product', async browser => {
    const searchBox = await browser.findElement(By.css('#search-input'))
    await searchBox.type('running shoes')
    await browser.press(Key.Enter)
    await browser.wait(Until.elementIsVisible(By.css('.search-results')))
  })

  step('Add to cart', async browser => {
    const firstResult = await browser.findElement(By.css('.product-card:first-child .add-to-cart'))
    await firstResult.click()
    await browser.wait(Until.elementIsVisible(By.css('.cart-notification')))
  })
}

Key Concepts: Load Profiles

Flood supports standard load profiles regardless of which script type you're using:

Ramp-up: gradually increase virtual users over a specified duration. Standard for preventing a cold-start spike from distorting early results.

Constant load: maintain a fixed number of users for a duration. Good for steady-state throughput testing.

Stepped load: increase users in discrete steps, holding each step for a period. Useful for identifying the threshold where response times degrade.

Spike: jump to maximum load instantly. Tests your application's behavior under sudden traffic surges — flash sales, viral content, DDoS scenarios.

For JMeter tests, Flood respects the thread groups in your .jmx file and multiplies them across nodes. For Gatling and Element, you configure the load profile in the Flood UI when launching a flood.

When to Use Flood vs Self-Hosted

Use Flood when:

You need to test from multiple geographic regions simultaneously
Your test runs are infrequent (a few times per week or month) — the operational overhead of self-hosted doesn't pay off
Your team already has JMeter or Gatling scripts and wants to run them at scale without setting up distributed infrastructure
You need results fast — a Flood test can be running within minutes of uploading your script

Use self-hosted when:

You run tests continuously as part of every CI build — per-node-hour pricing adds up quickly at high frequency
Your application is air-gapped or in a network that can't be reached from Flood's infrastructure (though on-premise agents partially address this)
You need deep control over infrastructure — specific instance types, custom JVM settings, network configurations
Compliance requirements prohibit sending any traffic through third-party cloud infrastructure

Use k6 instead when:

You want JavaScript-based scripting with a modern CLI-first workflow
You're building tests from scratch and aren't committed to JMeter/Gatling

Pricing Model

Flood charges by node hours — the number of nodes multiplied by the hours they run. A 10-node test running for 2 hours consumes 20 node hours.

There's a free tier that covers small tests (limited node hours per month). The free tier is enough for exploratory testing and script validation, but not for serious load tests.

Pricing for paid plans is consumption-based. This makes Flood economical for infrequent, large tests but potentially expensive for continuous testing pipelines. Run the math for your use case before committing — for a team running 10-node tests daily, self-hosted infrastructure on EC2 often costs less over a year.

Results and Observability

The Flood dashboard shows real-time results as the test runs:

Requests per second (aggregate and per transaction)
Response time percentiles (mean, 95th, 99th)
Error rate and error breakdown by type
Concurrent users over time
Regional breakdown (for multi-region tests)

Results are retained after the flood completes and can be exported as CSV or JSON. The dashboard doesn't replace your application's own monitoring — you still want APM data, database query performance, and infrastructure metrics from your own tools. Flood tells you what users experienced; your APM tells you why.

Summary

Flood.io is a solid choice for teams that have existing JMeter or Gatling test suites and want to run them at scale without managing infrastructure. The geographic distribution feature is genuinely useful for applications with global user bases. Flood Element fills a gap that pure-API load testing misses — real browser sessions under load.

The main constraint is pricing at high test frequency. If load testing is part of your daily CI pipeline, self-hosted or a tool with unlimited plan pricing will likely be cheaper. If you run load tests a few times per sprint as a release gate, Flood's operational simplicity makes it worth the per-node cost.