Why Gload is YAML-first

Most load testing tools ask you to write a script before you can run a test. That's the right choice for complex, branching scenarios — but most load tests aren't complex. Most are: hit this endpoint, at this rate, for this long, and tell me what broke.

Gload starts from that second case.

A test is data, not a program

scenario: checkout-flow
target: api.example.com
duration: 30s
vus: 50

stages:
  - ramp: 10s
    to: 50
  - hold: 20s

That's a complete load test. No imports, no boilerplate, nothing to compile. If you can read a YAML file, you can read what this test does — which matters as much for code review as it does for running it yourself.

Inspired by k6, not cloning it

k6's scripting model is genuinely good for the scenarios that need it — multi-step flows, custom logic, complex assertions. We're not trying to replace that. Gload is for the far more common case where you don't need a scripting language at all, and shouldn't have to reach for one to get started.

Where we are

Gload is early and in active development — the example above shows the direction, not a finished feature set. We'll post here as pieces land. If you want to follow along, we're on GitHub.