Core concepts

Plan

The YAML configuration becomes an ordered []Workload. Each configured scenario becomes one workload, and the CLI runs those workloads sequentially in file order.

Scenario

A scenario defines one repeated sequence of HTTP steps and one virtual-user target. Its total duration contains three phases:

1. ramp from zero to virtual_users over ramp_up_duration;
2. hold the target for the time left after both ramps; and
3. ramp back to zero over ramp_down_duration.

The ramp durations cannot add up to more than the total scenario duration.

Virtual user

A virtual user runs independently in its own goroutine. While active, it executes every configured step in order and then starts the sequence again. It stops when its context is cancelled during ramp-down, manual cancellation, or scenario completion.

Virtual-user pool

The pool owns the active virtual users. It adds users during ramp-up, publishes their outcomes to the scenario, and removes them during ramp-down. The current configuration limit is 300 virtual users per scenario.

Step and action

The YAML field is named steps. Internally, each step becomes an action containing:

• a required name;
• a randomized think-time range; and
• one HTTP request.

Think time occurs before the request on every iteration. Loady currently supports GET, POST, PATCH, and DELETE requests.

Request

Each request requires its own absolute URL and timeout. The top-level target is not currently used as a base URL. Optional headers and a string body can be supplied; environment placeholders are resolved only inside header values.

Loady sends the request and records the status code and elapsed request time. It closes the response body without retaining or inspecting its contents.

Outcome and distribution

Every action produces an outcome. A scenario aggregates outcomes into:

• total request count;
• successful and unsuccessful outcome counts;
• HTTP status-code counts; and
• p50, p90, p95, and p99 latency fields printed by the CLI.

Any HTTP response currently counts as successful, including 4xx and 5xx responses. Transport errors and request deadline failures are unsuccessful. Assertions, response-body checks, configurable success status codes, and a dedicated throughput summary are not currently implemented.

Cancellation

The CLI creates a cancellable context for the run and propagates it through scenarios, virtual users, actions, and HTTP requests. An interrupt or termination signal stops ongoing work and allows active goroutines to exit.