# Load Test Plan

> Designs and executes load tests, covering scenario design, baseline capture, execution configuration, results analysis, and reporting for k6, Locust, Gatling, and JMeter.

- Skill: `cloudthinker-ai/load-test-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cloudthinker-ai/load-test-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cloudthinker-ai/load-test-plan/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra, Coding & Dev Tools, Monitoring & Observability, Testing & QA
- Tags: Capacity Planning, Gatling, Jmeter, K6, Load Testing, Locust, Performance Testing
- Author: cloudthinker-ai (https://skillmd.com/u/cloudthinker-ai)
- Updated: 2026-08-22
- Page: https://skillmd.com/skills/cloudthinker-ai/load-test-plan

---


# Load Test Plan Skill

Design and execute load testing for **{{ service_name }}** targeting **{{ target_rps }} RPS**.

## Workflow

### Step 1 — Test Objectives

Define what this load test will validate:

```
TEST OBJECTIVES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Target: {{ service_name }}
Target RPS: {{ target_rps }}
Duration: {{ test_duration | "30 minutes" }}

Goals:
[ ] Validate service handles {{ target_rps }} RPS within SLO
[ ] Identify performance bottlenecks before they hit production
[ ] Establish performance baseline for regression detection
[ ] Determine maximum throughput before degradation
[ ] Validate autoscaling behavior under load

Success criteria:
  - P95 latency: < ___ms
  - P99 latency: < ___ms
  - Error rate: < ___%
  - Throughput: ≥ {{ target_rps }} RPS sustained
```

### Step 2 — Test Scenarios

```
SCENARIO DESIGN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Scenario 1 — Baseline (current production traffic)
  - RPS: [current production average]
  - Duration: 10 minutes
  - Purpose: Capture baseline metrics

Scenario 2 — Target Load
  - RPS: {{ target_rps }}
  - Duration: {{ test_duration | "30 minutes" }}
  - Ramp-up: 5 minutes linear ramp
  - Purpose: Validate target capacity

Scenario 3 — Peak Load (2x target)
  - RPS: [2x {{ target_rps }}]
  - Duration: 15 minutes
  - Purpose: Find breaking point and validate graceful degradation

Scenario 4 — Stress Test (ramp to failure)
  - RPS: Ramp from {{ target_rps }} to max, +10% every 2 minutes
  - Purpose: Determine absolute maximum throughput

Scenario 5 — Soak Test (optional)
  - RPS: {{ target_rps }}
  - Duration: 2-4 hours
  - Purpose: Detect memory leaks, connection pool exhaustion
```

### Step 3 — Test Configuration

```
REQUEST PROFILE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| Endpoint | Method | Weight | Payload |
|----------|--------|--------|---------|
| [path] | GET | 60% | - |
| [path] | POST | 25% | [size] |
| [path] | PUT | 10% | [size] |
| [path] | DELETE | 5% | - |

Test data:
[ ] Test user accounts provisioned
[ ] Test data seeded in database
[ ] Authentication tokens pre-generated
[ ] Request payloads prepared (realistic size/complexity)

Environment:
[ ] Test environment isolated from production
[ ] Test environment matches production spec (or scaled proportionally)
[ ] Load generators provisioned in same region as target
[ ] Monitoring dashboards configured
```

### Step 4 — Pre-Test Checklist

```
PRE-TEST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Stakeholders notified of test window
[ ] Target service team aware and monitoring
[ ] Baseline metrics captured (before test)
[ ] Rate limiters adjusted or bypassed for test traffic
[ ] Autoscaling verified (or fixed replica count for controlled test)
[ ] Test script dry-run successful (low RPS sanity check)
[ ] Kill switch ready to stop test immediately
[ ] Database capacity sufficient for test data volume
```

### Step 5 — Execution & Monitoring

```
DURING TEST — MONITOR
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Service metrics:
[ ] Request rate (actual vs target)
[ ] Error rate (by status code: 4xx, 5xx)
[ ] Latency (P50, P95, P99)
[ ] Throughput (successful requests/sec)

Infrastructure metrics:
[ ] CPU utilization (per instance and aggregate)
[ ] Memory utilization
[ ] Network I/O
[ ] Disk I/O (if applicable)

Dependency metrics:
[ ] Database query time and connection pool usage
[ ] Cache hit ratio and latency
[ ] External API response time
[ ] Message queue depth (if applicable)

ABORT CRITERIA:
[ ] Error rate > 10% for > 2 minutes
[ ] Service becomes unresponsive
[ ] Downstream services impacted
[ ] Data corruption detected
```

### Step 6 — Results Analysis

```
RESULTS TEMPLATE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| Metric | Baseline | Target Load | Peak Load | SLO | Status |
|--------|----------|------------|-----------|-----|--------|
| RPS achieved | ___ | ___ | ___ | {{ target_rps }} | PASS/FAIL |
| P50 latency | ___ms | ___ms | ___ms | ___ms | PASS/FAIL |
| P95 latency | ___ms | ___ms | ___ms | ___ms | PASS/FAIL |
| P99 latency | ___ms | ___ms | ___ms | ___ms | PASS/FAIL |
| Error rate | ___% | ___% | ___% | ___% | PASS/FAIL |
| Max CPU | ___% | ___% | ___% | 80% | PASS/FAIL |
| Max memory | ___% | ___% | ___% | 80% | PASS/FAIL |

Breaking point: ___ RPS (where error rate > 1% or P95 > SLO)
Headroom: ___% above target RPS before degradation
```

### Step 7 — Recommendations

Produce actionable recommendations:
1. **Bottlenecks identified**: [resource, threshold, impact]
2. **Optimization opportunities**: [specific tuning recommendations]
3. **Scaling recommendations**: [infrastructure changes needed]
4. **Retest needed**: [YES/NO, with specific scenarios]

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |

## Output Format

Produce a load test report with:
1. **Test configuration** (scenarios, endpoints, traffic profile)
2. **Results table** with metrics per scenario vs SLO
3. **Bottleneck analysis** with graphs/data showing saturation points
4. **Recommendations** prioritized by impact
5. **Comparison** with previous test runs (if available)