Safe load-test execution

Bounds authorized load tests by environment, resource budgets and stop conditions with verifiable cleanup afterward.

safe-execution-test-cleanup

Team members using this skill

See how it helps

When is it useful?

Use before generating traffic that could affect shared services or costs.

What does it help you do?

Confirms target scope and hard duration, traffic and spend limits.
Defines automatic stop thresholds and tracks owned test processes.
Checks drained queues and approved cleanup while preserving evidence.

Try asking this

Prepare a staging load test with tenant-isolated records, stop thresholds and proof no load workers remain afterward. Trigger a stop threshold during a short rehearsal. Record terminated generators, drained owned jobs and retained evidence; clean only explicitly scoped test resources.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Safe Execution & Test Cleanup

When to Use

Use before, during, and after executing any load, stress, spike, soak, or benchmark run.

Pre-Flight Safety Gate (Mandatory Before Starting Traffic)

1. Scope Authorization & Environment Boundaries

Confirm which target environment (localhost, isolated CI container, dedicated staging, or explicitly authorized target) is under test.
Never run unapproved high-volume load tests against production or shared third-party SaaS endpoints.
Audit every external side effect triggered by the tested code path before sending load:
- Outbound emails, SMS, push notifications, or webhook deliveries.
- Real payment gateway charges, invoicing API calls, or external government tax reporting.
- Paid LLM / AI provider API calls, embeddings, or metered third-party APIs.
Route external side effects to local/staging sandboxes or deterministic latency-accurate stubs, and state clearly in the report which dependencies were stubbed vs. live.

2. Hard Resource, Time, and Cost Budgets

Every test run must define explicit caps before launch:

Maximum Duration (maxDuration): Hard wall-clock ceiling (e.g., 60s–300s for local/CI load checks) so a hung script never runs indefinitely.
Maximum Request / VU Ceiling (maxVUs, max RPS): Bounded upper limit on concurrency and arrival rate.
Cost & Token Ceiling (for AI/Cloud runs): Maximum total requests, tokens, or dollar budget allowed before immediate termination.

3. Automated Kill-Switch / Abort Thresholds

Configure automatic abort triggers (abortOnFail: true in k6 thresholds or harness circuit breakers) that halt the test immediately when:

Error rate (http_req_failed or 5xx/timeout rate) exceeds the safety ceiling (e.g., > 10% sustained over 15s during a baseline test, or > 35% during a stress test).
Target host health check becomes unreachable or memory/disk approaches critical OS exhaustion.
Keep a manual stop mechanism (SIGINT / PID tracking / cancellation token) ready at all times.

Deterministic Post-Test Cleanup & State Verification

Never leave a test environment degraded or polluted after a run completes or aborts:

Zero Orphaned Load Processes:
- Verify that all load generator processes (k6, locust, worker subprocesses, background timers) have exited cleanly (ps / task check).
Queue & Background Worker Drain:
- Confirm that any in-flight jobs enqueued during the test have either drained to 0 or been purged from the test queue so background workers do not keep spinning after the test ends.
Test Data & Tenant Isolation Cleanup:
- Tag all synthetic test records (e.g., dedicated test tenant ID, email prefix loadtest+..., or run correlation header X-Load-Test-Run-Id) and clean up temporary test artifacts, uploaded files, or rate-limit keys so subsequent tests start from a clean baseline.
Preserve Reproducible Artifacts:
- Save the exact test script version, target git SHA, environment parameters, and summary JSON/metrics output so post-fix re-runs can be compared apples-to-apples.

Included files 1

SKILL.md