Load Test Node

The Load Test node runs load and performance tests against HTTP endpoints, simulating multiple virtual users (VUs) in parallel. It generates PNG visual evidence with detailed metrics and supports automatic pass/fail criteria via thresholds.

Overview

Test Types

Each test type automatically generates a different load profile from the VUs and Duration fields.

Configuration

Request

Load Configuration

For Smoke, the VUs field is fixed at 1 and not displayed.
For Soak, the default duration is 1800s (30 min).
For Breakpoint, VUs represents the maximum VUs to be reached.

How Breakpoint works

The test divides the total duration into ~30s steps, progressively increasing VUs:

VUs: 10 | Duration: 60s  →  2 steps of 30s
  Step 1: 0s → 30s  →  5 VUs
  Step 2: 30s → 60s →  10 VUs

Custom Stages

Enable Custom in the Stages section to manually define the load profile:

Example stages for a manual stress test:

Authentication

Using Saved Credentials

Select an HTTP/API credential. The base URL and authentication data are applied automatically:

1. Select the credential in the Credential field
2. The base URL is automatically filled in the URL field
3. Complete with the endpoint path: /api/checkout

Manual Authentication

Thresholds

Thresholds define automatic pass/fail criteria. If any threshold is not met, the node is marked as FAILED.

Common threshold examples:

Without configured thresholds, the node always passes (as long as the endpoint responds).

Outputs

metrics object structure

{
  "totalRequests": 1141,
  "errorCount": 0,
  "errorRate": 0.0,
  "rps": 34.49,
  "avgDuration": 212,
  "minDuration": 98,
  "maxDuration": 668,
  "p50": 182,
  "p90": 332,
  "p95": 451,
  "p99": 579
}

Accessing Outputs

// Check if passed
{{ steps["load-test"].outputs.passed }}  →  true

// Total requests
{{ steps["load-test"].outputs.metrics.totalRequests }}  →  1141

// p95 latency
{{ steps["load-test"].outputs.metrics.p95 }}  →  451

// Error rate
{{ steps["load-test"].outputs.metrics.errorRate }}  →  0.0

// RPS
{{ steps["load-test"].outputs.metrics.rps }}  →  34.49

Generated Evidence

The node automatically generates two PNG charts as execution evidence:

1. Summary Report (load-test-report.png)

Consolidated view with:

• Metric cards (p50, p95, p99, Avg, RPS, Requests, Errors, Error Rate)
• Horizontal bar chart with latency distribution
• Throughput over time chart (req/s)
• Status pills for each configured threshold
• Footer with executed stages

2. RPS × Latency Timeline (load-test-timeline.png)

Dual-axis chart with:

• Blue bars (left axis): RPS over time
• Orange line (right axis): Average latency over time
• Purple dashed line (right axis): p95 latency over time

The timeline chart is especially useful for Breakpoint and Stress tests, where you can visually identify the exact moment latency starts rising in response to increased load.

Practical Examples

Smoke test — Basic validation

Type: Smoke
URL: https://api.example.com/health
Method: GET
Duration: 10s

Ideal to run at the start of a test flow — ensures the environment is up.

Load test — Normal load with thresholds

Type: Load
URL: https://api.example.com/products
Method: GET
VUs: 20
Duration: 60s
Thresholds:
  - p95 < 500
  - errorRate < 1

Stress test — System limits

Type: Stress
URL: https://api.example.com/checkout
Method: POST
VUs: 100
Duration: 120s
Body: { "productId": "123", "quantity": 1 }
Auth: Bearer → {{ variables.API_TOKEN }}
Thresholds:
  - p99 < 2000
  - errorRate < 5

Breakpoint — Finding the breaking point

Type: Breakpoint
URL: https://api.example.com/search
Method: GET
Max VUs: 200
Duration: 300s
Thresholds:
  - p95 < 1000
  - errorRate < 2

The system will progressively increase from 1 to 200 VUs in ~30s steps. When p95 exceeds 1000ms or errors surpass 2%, the node marks as failed — indicating the breaking point.

Chaining with other nodes

[Load Test: Smoke]
    │ outputs.passed = true
    ▼
[If: {{ steps.smoke.outputs.passed }}]
    │ true  → [Load Test: Full load]
    │ false → [Log: "Smoke failed — environment unavailable"]

Queue Isolation

The Load Test node runs in a separate queue (qanode-load-tests) to avoid interfering with other running flows.

To configure a dedicated Load Test worker:

WORKER_QUEUES=load-tests node dist/start.js

For a worker that processes both queues:

WORKER_QUEUES=executions,load-tests node dist/start.js

Tips

• Start with Smoke before running load tests — ensures the endpoint is responding correctly
• Configure thresholds so the test fails automatically when the system degrades, without having to analyze numbers manually
• Use the timeline chart to identify the exact moment of degradation in Breakpoint and Stress tests
• Think Time simulates human behavior — useful for Soak tests where you want continuous but realistic load
• Saved credentials make it easy to run in different environments (staging, production) without changing the flow
• For reliable tests, up to 100 VUs per worker instance. Above that, consider a dedicated worker