Steps
A spec's steps are the ordered list of HTTP requests every virtual user executes on every iteration. When you press Start, each VU runs the full step sequence in order, waits the configured think-time, and loops again until the test's duration or iteration count is reached.
The Steps Panel
Switch to the Steps view from the secondary sidebar to edit the step sequence. The panel is laid out as a vertical rail with four distinct zones:
- •Steps header — click the + to create a new blank step inline, or open the import dropdown to pull existing requests in
- •Before All (sticky top) — lifecycle script that runs once at the start of the test. A small dot appears when the script is non-empty
- •Step list (scrollable) — every step in order, drag-and-drop to reorder
- •After All (sticky bottom) — lifecycle script that runs once at the end of the test
Creating Steps
The + button in the Steps header opens an inline create form. Type a step name and press Enter — the new step is appended to the end of the list and becomes the selected step.
Next to + there's an Import dropdown with three sources:
| Source | What it imports |
|---|---|
| Import from Box | Pick any saved request from the Box — method, URL, headers, body, auth are all copied onto the new step |
| Import from Projects | Pick endpoints from an OpenAPI project. Multiple endpoints become multiple steps in one go |
| Import from Flows | Import individual steps out of an existing flow — useful when promoting a flow into a load test |
OAuth2 is stripped on import: the load-test step editor deliberately excludes OAuth2 as an auth type (excludeAuthTypes=['oauth2']). If the imported request used OAuth2, Tigrister surfaces an Auth Stripped Warning modal so you can swap in a Bearer token or another auth mode before running the test.
Reordering Steps
Each step row is draggable. Grab a step and drop it anywhere in the list — the store callsreorderSteps(dragIndex, dropIndex) to persist the new order immediately. The sort order is what VUs execute on every iteration.
The Step Editor
Selecting a step opens a detail panel on the right. The layout is the same as a standard HTTP tab: a method + URL line at the top, then a Request / Response toggle. The request editor is organized into the same sub-tabs you'll recognize from the HTTP client:
- •Body — raw, form-data, x-www-form-urlencoded, or binary file
- •Params — query string parameters
- •Vars — step-scoped variables
- •Headers — request headers
- •Auth — Basic / Bearer / API Key / OIDC (OAuth2 excluded)
- •Processors — pre-script, post-script, assertions and extractions
The Try button at the top of the step fires a single request against the target so you can verify everything is wired up before running the full test with thousands of VUs.
Variable Extractions
Extractions pull values out of a step's response and store them under a name that later steps can reference. This is how you chain requests — for example, extract an id from a POST response and use it as a path parameter in the next GET.
Load Test extractions use the same four sources as Flow Runner extractions, via the sharedFlowExtraction type:
| Source | How it works |
|---|---|
| json_path | JSONPath expression against the response body (e.g. $.data.token) |
| header | Response header by name (e.g. Location) |
| regex | Regular expression with a capture group, matched against the body |
| status | The numeric HTTP status code of the response |
Per-Step Pre & Post Scripts
Beyond Before All / After All, every step can have its own preScript andpostScript snippets that run on every VU iteration — before the request is sent and after the response is received. The editor lives in the Processors sub-tab of the step.
These scripts share the same tg.* runtime as Before All / After All, but they're hot-path code: they execute thousands of times per second under load. Keep them tight — simple variable extraction, a small amount of logic, no heavy JSON walks.
Assertions
Steps carry the same assertion engine as the rest of Tigrister: status code equals, body JSON path equals, body contains, header equals, and so on. Assertions run on every VU iteration and feed into the errorBreakdown.assertion counter.
Whether an assertion failure fails the whole run depends on the Fail on assertion errors toggle in the Dashboard's Test Criteria section — see the Thresholds section for details.
Auth Credentials & Persistence
The Auth sub-tab of a step is a security boundary. Whatever you type into the credential fields behaves very differently from every other field on the step:
- •The auth type persists, the plain-text values do not. When the spec is saved — and therefore when the spec group is committed to git — the selected type (Bearer / Basic / API Key / From Scheme) is kept along with structural fields (URLs, scopes, key names), but the actual token, username/password, and API key value are stripped to empty strings
- •Template references are preserved. If a credential field contains a variable reference like
{{api_token}}, Tigrister treats it as a pointer, not a secret — it's stored verbatim. Anyone who pulls the spec from git gets the reference back, unchanged - •Plain values are memory-only. They survive as long as the Load Test panel is open in your session. Close the tab, reopen the spec, and any plain credential you typed is gone — you have to type it again
CLI & CI/CD implication: headless load-test runs have no one to type credentials. That's why the pattern for CI-driven runs is: reference a secret variable in the Auth sub-tab ({{api_token}}), mark it as Secret in the spec-group environment panel (OS Secret or Vault), and let the CLI/CI runner supply the actual value from its own secret store at runtime. The committed spec carries only the reference — never the secret.