load-testing-apis

name	load-testing-apis
description	Execute comprehensive load and stress testing to validate API performance and scalability. Use when validating API performance under load. Trigger with phrases like "load test the API", "stress test API", or "benchmark API performance".
allowed-tools	Read, Write, Edit, Grep, Glob, Bash(api:load-*)
version	1.24.0
author	Jeremy Longshore <[e-mail]>
license	MIT
tags	["api","testing","performance","scaling"]
compatibility	Designed for Claude Code, also compatible with Codex and OpenClaw

Load Testing APIs

Overview

Execute comprehensive load, stress, and soak tests to validate API performance, identify bottlenecks, and establish throughput baselines. Generate test scripts for k6, Artillery, or wrk that simulate realistic traffic patterns with configurable virtual user ramp-up, request distribution, and failure threshold assertions.

Prerequisites

• Load testing tool installed: k6 (recommended), Artillery, wrk, or Apache JMeter
• Target API deployed in a staging/performance environment (never load test production without safeguards)
• Monitoring stack accessible: Grafana/Prometheus, Datadog, or CloudWatch for correlating test results with server metrics
• API authentication credentials for testing (API keys, test user JWT tokens)
• Baseline performance SLOs defined (target p95 latency, max error rate, minimum throughput)

Instructions

1. Read the API specification and route definitions using Glob and Read to build a complete list of endpoints, identifying high-traffic paths and resource-intensive operations.
2. Define test scenarios modeling realistic user behavior: browsing (80% reads), checkout (mixed reads + writes), and spike traffic patterns with appropriate think times between requests.
3. Generate k6 or Artillery test scripts with configurable stages: ramp-up (2 min), sustained load (10 min), spike (2 min at 3x), and cool-down (2 min).
4. Configure request distribution to match production traffic patterns -- weighted random selection across endpoints rather than uniform distribution.
5. Add threshold assertions for pass/fail criteria: p95 response time < 500ms, error rate < 1%, throughput > 100 requests/second.
6. Implement data-driven requests using CSV or JSON fixtures for realistic payloads, unique user IDs, and varied query parameters to avoid cache-only testing.
7. Execute baseline test at expected production load, then gradually increase to 2x, 5x, and 10x to identify the breaking point and saturation behavior.
8. Analyze results: correlate latency spikes with server metrics (CPU, memory, DB connections, event loop lag), identify the bottleneck (database, network, compute), and document findings.
9. Generate a performance report comparing results against SLO thresholds with recommendations for optimization.

See ${CLAUDE_SKILL_DIR}/references/implementation.md for the full implementation guide.

Output

• ${CLAUDE_SKILL_DIR}/load-tests/scenarios/ - k6/Artillery test scripts per traffic scenario
• ${CLAUDE_SKILL_DIR}/load-tests/data/ - Test data fixtures (users, payloads, tokens)
• ${CLAUDE_SKILL_DIR}/load-tests/thresholds.json - Pass/fail threshold configuration