Load tests

A load test sends a fixed load to an HTTP project from inside the project's region and reports how the function held up: latency percentiles, the error rate and the requests per second, next to how far the project scaled and how many cold starts the load caused. It runs k6 with a script RunR generates — there are no user scripts.

Project → Load test (console), POST /api/projects/{project}/load-tests (API), runr loadtest (CLI), load_test_run / load_test_get (MCP).

Test traffic is metered. The requests of a load test reach the project's deployment like any other traffic: its sessions, CPU, memory and cold starts are metered and billed (pay as you go) exactly the same way.

What a test can choose#

The installation can lower the largest choices (observability.loadTest.maxUsers, maxDurationSeconds).

Abuse guard#

• Only the project's own URL. The target host is the project's function host (<slug>.<region domain>) or a custom domain of the project whose ownership was verified and that is routed on the region (status active, custom domains). The k6 pod resolves that host to the region's own ingress (see below) and does not follow redirects.
• One test per project at a time (409 load_test_running). A test past its deadline (its duration plus the start time) no longer holds the project.
• A daily limit per organization (observability.loadTest.dailyLimit, default 20; 429 daily_limit_reached). In a multi-tenant install every organization counts its own tests.
• A pod quota per region (observability.loadTest.maxConcurrentPerRegion, default 5): the ResourceQuota of the load-test namespace. A test that does not get a pod within a minute fails.
• The project must be HTTP-triggered, deployed (an active deployment) and not stopped; its region must have a cluster connection, be active and not moving.

How it runs#

1. The API checks the guard, stores the test (pending) and broadcasts it (load_test.updated).
2. StartLoadTestJob prepares the region's load-test namespace runr-loadtest (once, then at most every ten minutes again), reads the ClusterIP of the region's Traefik, writes the generated script into a ConfigMap and creates the k6 Job — the test is running.
3. CheckLoadTestJob follows the Job every 5 seconds. When k6 is done it reads the results line from the pod's log, adds the scaling figures of the test window and removes the Job and its ConfigMap — the test is completed (or failed with the reason). The one who started it gets a notification (load_test.completed / load_test.failed).

The namespace runr-loadtest (observability.loadTest → OBS_LOADTEST_NAMESPACE):

The Job lt-<id>: one pod (backoffLimit: 0), activeDeadlineSeconds = duration + 180 s, ttlSecondsAfterFinished: 600, no service account token, no secrets, the non-root k6 user, a read-only root file system, CPU 250m–1 and memory 256–512 MiB. Its image is ghcr.io/brf-tech/runr/reqs/k6:1.8.2 (the reqs mirror of docker.io/grafana/k6; observability.loadTest.image points it elsewhere).

The script runs the constant-vus executor with the chosen users and duration, maps the target host to the Traefik ClusterIP (k6 option hosts), sends the requests over HTTPS (OBS_LOADTEST_TARGET_SCHEME) without verifying the certificate — the address is the region's own ingress, not a name looked up anywhere — and prints its results with handleSummary as one line RUNR_LOADTEST_SUMMARY {json}. So the test measures the function behind the region's ingress, not the internet between a client and the region. The project's own NetworkPolicies are not involved: the requests enter the project namespace through Traefik like any other request.

When the region goes#

• Uninstalling Knative Serving from the region (Uninstall Serving, or the full uninstall-knative, Regions) removes the namespace with its policies, its quota and the Jobs still running in it: the ingress the tests target goes with Serving. The region's running tests of the organization that uninstalls end as failed (Knative Serving was uninstalled from the region); those of other organizations end at their next check, when their Job is gone. The next test after a new install applies the namespace again. A namespace of that name that RunR did not create (without app.kubernetes.io/managed-by: runr and app.kubernetes.io/component: load-test) stays.
• The end of a tenant's share of a platform region (detach) removes that tenant's Jobs and their ConfigMaps from the namespace (label runr.dev/tenant) and ends its tests there as failed (The organization no longer uses the region). The namespace stays for the others.

Results#

The tab shows the latest run and the last five runs side by side (the best value of each row marked), so a change can be compared with the runs before it. A run whose k6 ended without results (a script error, a pod that could not start) fails with the end of k6's log.

API#

Errors#

Permissions#

Running and stopping a test needs projects.deploy on the project — it sends metered traffic to the deployment; reading tests and results needs metrics.view. The MCP tools and the CLI follow the same permissions. Audit log: load_test.start (host, method, path, users, duration and whether a body was sent — never the body) and load_test.cancel.

Configuration#

Helm values observability.loadTest.* (helm-values.md):

Set with extraEnv: OBS_LOADTEST_NAMESPACE (runr-loadtest), OBS_LOADTEST_TARGET_SCHEME (https), OBS_LOADTEST_MAX_BODY_BYTES (4096), OBS_LOADTEST_START_GRACE_SECONDS (180), OBS_LOADTEST_TTL_SECONDS (600), OBS_LOADTEST_CPU_REQUEST / _LIMIT (250m / 1), OBS_LOADTEST_MEMORY_REQUEST / _LIMIT (256Mi / 512Mi).

Related files#