Load Test Plan Template with a Worked Example
A load test plan answers ten questions before any traffic is sent: why you are testing, what is in scope, what load model and numbers you will use, which test types run when, in which environment, with what data, what counts as a pass, what you will monitor, what could go wrong and how you stop it, and who signs off. Below is each section with a filled-in example for a fictional "Acme API checkout" service, followed by a blank Markdown version you can copy.
"Acme API checkout" is fictional. Every number in the example sections is illustrative, chosen to show how the sections fit together. Replace them with your own measurements.
1. Objectives and scope
State the decision the test supports. "Verify performance" is not an objective; "confirm checkout handles the holiday forecast with 50% headroom before the Nov 20 freeze" is. Scope should list what is in, what is out, and why.
| Field | Example: Acme API checkout |
|---|---|
| Objective | Confirm the checkout API sustains 1.5x forecast peak with thresholds met, and find the breaking point. |
| Decision it supports | Go / no-go for the holiday promotion; whether to add a read replica. |
| In scope | POST /v1/cart, GET /v1/cart/{id}, POST /v1/checkout/quote, POST /v1/orders |
| Out of scope | Payment provider (stubbed), email service, admin API, frontend rendering |
2. Workload model
Write down where the numbers come from so reviewers can challenge the assumptions. Choose open (arrival rate, fixed RPS) or closed (fixed VUs) deliberately; for public APIs, an open model is usually closer to reality. See open vs closed workload models.
Measured peak (last holiday, 1-min resolution): 240 RPS across checkout endpoints
Growth since then: x 1.30
Forecast peak: 240 x 1.30 = 312 RPS
Target (1.5x headroom): 312 x 1.5 = 468 RPS -> round to 470 RPS
Model: open (arrival rate)| Endpoint | Share | RPS at target | Notes |
|---|---|---|---|
GET /v1/cart/{id} | 45% | 211 | Read, cacheable per user |
POST /v1/cart | 30% | 141 | Write, session store |
POST /v1/checkout/quote | 17% | 80 | Calls tax and shipping services |
POST /v1/orders | 8% | 38 | Write, stock reservation, payment stub |
The RPS calculator converts between users, sessions and requests if your source data is in users.
3. Test types and schedule
| # | Type | Profile | Duration | Date (example) |
|---|---|---|---|---|
| 1 | Smoke | 10 RPS | 2 min | Mon, week 1 |
| 2 | Baseline | Current peak, 240 RPS | 15 min | Tue, week 1 |
| 3 | Load | Ramp 5 min to 470 RPS, hold | 30 min | Thu, week 1 |
| 4 | Stress / breakpoint | +50 RPS every 5 min until thresholds break | Until stop | Tue, week 2 |
| 5 | Spike | 240 to 625 RPS in 30 s, hold 5 min | 10 min | Wed, week 2 |
| 6 | Soak | 312 RPS | 4 h | Thu, week 2 |
Re-tests after fixes repeat test 3 and the failing test, with the same script and data.
4. Environment and test data
Document how the test environment differs from production, because every difference is a caveat on the result.
| Item | Production | Test environment (example) |
|---|---|---|
| App instances | 6 x 2 vCPU | 6 x 2 vCPU (same) |
| Database | Primary, 8 vCPU, 420 GB | Primary, 8 vCPU, restored snapshot 410 GB |
| CDN / WAF | Yes | WAF in front, load generator IPs allowlisted |
| Payment provider | Live | Stub with 300–800 ms latency |
Data: 50,000 synthetic customer accounts, 20,000 SKUs with stock set high enough not to sell out mid-test, unique cart per virtual user. Test orders are tagged source=loadtest and deleted by script after each run.
5. Success criteria and thresholds
Numeric, per endpoint, agreed before the run. Thresholds are checked over the steady-state hold, excluding ramp-up.
| Endpoint | p95 | p99 | Error rate | Auto-stop if |
|---|---|---|---|---|
GET /v1/cart/{id} | < 150 ms | < 400 ms | < 0.5% | p95 > 1 s for 1 min |
POST /v1/cart | < 250 ms | < 600 ms | < 0.5% | p95 > 1 s for 1 min |
POST /v1/checkout/quote | < 500 ms | < 1,200 ms | < 1% | errors > 5% |
POST /v1/orders | < 900 ms | < 2,000 ms | < 0.1% | errors > 2% |
| Overall | Achieved RPS within 2% of target during hold | Generator CPU > 85% | ||
For why both p95 and p99 are listed, see p95 vs p99. Most tools can enforce these during the run; in LoadTester, for example, you set p95 and error-rate thresholds with auto-stop on breach so a failing stress test ends itself.
6. Monitoring
- Client side: RPS, p50/p95/p99 per endpoint, error rate by type, active VUs.
- Service: CPU, memory, GC pauses, request queue, HTTP client pool usage per instance.
- Database: CPU, active connections vs
max_connections, lock waits, slow query log at 200 ms. - Dependencies: tax and shipping service latency and error rate, stub latency.
- Generator: CPU, network, open connections.
Name the dashboard links in the plan and sync clocks; mark each test start and stop on the dashboards. How to read load test results covers what to look for afterwards.
7. Risks and rollback
| Risk | Likelihood | Mitigation | Stop / rollback |
|---|---|---|---|
| Test traffic affects shared database used by other teams | Medium | Run in agreed window, notify #db-team | Abort test; auto-stop thresholds |
| Test orders reach fulfillment | Low | Tag orders, fulfillment filter on source=loadtest | Cleanup script, manual check |
| WAF blocks generators mid-test | Medium | Allowlist generator IPs beforehand | Invalidate run, fix, repeat |
| Autoscaling adds cost or capacity that masks limits | Medium | Fix instance count for load and stress runs | Scale back after test |
The production load testing checklist covers the extra safeguards if any run targets production.
8. Roles and sign-off
| Role | Example | Approves |
|---|---|---|
| Test owner | Checkout team engineer | Scripts, data, execution |
| Service owner | Checkout tech lead | Objectives, thresholds, go / no-go |
| Environment owner | Platform / SRE | Environment, window, abort criteria |
| Affected teams | Database, fulfillment | Window and safeguards |
Copyable Markdown template
Paste this into your wiki, repository or ticket and fill in the brackets. It mirrors the sections above.
# Load Test Plan: [service / feature]
Version: [x.y] | Owner: [name] | Last updated: [YYYY-MM-DD]
## 1. Objectives
- Objective: [what we want to learn, in one sentence]
- Decision this supports: [go/no-go, sizing, architecture choice]
## 2. Scope
- In scope: [endpoints / flows]
- Out of scope: [systems, and why; stubs used]
## 3. Workload model
- Source data: [where peak numbers come from, resolution]
- Measured peak: [N] RPS on [date]
- Growth / events: x [factor] ([reason])
- Forecast peak: [N] RPS
- Target: [N] RPS ([headroom] x forecast)
- Model: [open (arrival rate) | closed (VUs)], think time: [s]
| Endpoint / flow | Share | RPS at target | Notes |
|---|---|---|---|
| [GET /...] | [%] | [N] | [ ] |
## 4. Test types and schedule
| # | Type | Profile | Duration | Date |
|---|---|---|---|---|
| 1 | Smoke | [N] RPS | [min] | [date] |
| 2 | Baseline | [N] RPS | [min] | [date] |
| 3 | Load | ramp to [N] RPS, hold | [min] | [date] |
| 4 | Stress | +[N] RPS every [min] until break | until stop | [date] |
| 5 | Spike | [N] to [N] RPS in [s] | [min] | [date] |
| 6 | Soak | [N] RPS | [h] | [date] |
## 5. Environment
| Item | Production | Test env |
|---|---|---|
| App instances | [ ] | [ ] |
| Database | [ ] | [ ] |
| CDN / WAF | [ ] | [ ] |
| Third parties | [ ] | [stubbed? latency?] |
Known differences and their effect on results: [ ]
## 6. Test data
- Accounts / entities: [counts, how generated]
- Uniqueness: [per VU / per iteration]
- Cleanup: [how test records are tagged and removed]
## 7. Success criteria (checked over steady state, ramp excluded)
| Endpoint | p95 | p99 | Error rate | Auto-stop if |
|---|---|---|---|---|
| [ ] | < [ms] | < [ms] | < [%] | [condition] |
Overall: achieved RPS within [%] of target; generator CPU < [%]
## 8. Monitoring
- Client: [dashboard link]
- Service: [dashboard link]
- Database: [dashboard link]
- Dependencies: [ ]
- Generator health: [ ]
## 9. Risks and rollback
| Risk | Likelihood | Mitigation | Stop / rollback |
|---|---|---|---|
| [ ] | [L/M/H] | [ ] | [ ] |
Abort criteria: [conditions] | Who can abort: [names]
Communication channel during test: [#channel]
## 10. Sign-off
| Role | Name | Date |
|---|---|---|
| Test owner | [ ] | [ ] |
| Service owner | [ ] | [ ] |
| Environment owner | [ ] | [ ] |
| Affected teams | [ ] | [ ] |
## Results (fill in after each run)
| Run | Date | Achieved RPS | p95 | p99 | Errors | Pass/Fail | Link |
|---|---|---|---|---|---|---|---|
| [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |Using the plan well
- Review it before the first run, not after. The point is to agree on thresholds while nobody has a result to defend.
- Keep it next to the test scripts. A Markdown file in the same repository as the scripts gets updated when the scripts change.
- Record every run in the results table, including invalid ones and why they were invalid. Shareable result links save copying charts.
- Revisit the workload model each quarter or before any major event; the forecast is the assumption most likely to be wrong.
Copy the template, fill in sections 1 to 3 first (objective, scope, workload model) and get the service owner to agree on them. The rest follows from those numbers. For where load tests fit in the release cycle overall, see the load testing strategy guide.
FAQ
How long should a load test plan be?
One to three pages for most services. The plan exists so that everyone agrees on the target, the pass criteria and the risks before the test runs. If a section does not change a decision, cut it.
Who should sign off on a load test plan?
The service owner who will act on the results, whoever owns the environment being tested (often platform or SRE), and anyone whose systems the test touches indirectly, such as a database team or a third-party integration owner. For production tests, add the on-call lead for the test window.
What is the difference between a load test plan and a load testing strategy?
A strategy describes how an organization approaches performance testing in general: which test types, when in the release cycle, which tools. A plan is specific to one test effort: this service, these targets, these dates, these people. Plans should reference the strategy rather than repeat it.
How do I choose the target load for the plan?
Start from measured production peaks at 1-minute resolution, apply expected growth and known events, and add headroom, typically 1.5x to 2x for peak tests. Write the derivation into the workload model section so reviewers can challenge the assumptions rather than the number.
Should the plan include pass/fail thresholds or just goals?
Thresholds. Vague goals such as 'the system should be fast' lead to arguments after the test. Write numeric thresholds per endpoint for p95, p99 and error rate, agreed before the run, so the result is a fact rather than an opinion.