# Event website load test authorization and stop plan

Use this worksheet to **plan**, approve and record an authorized load test. It contains no traffic-generating script or default request rate. Obtain permission from every system owner and check current provider policies before running anything.

## 1. Decision and authorization

| Item | Fill in |
|---|---|
| Event and expected sale/opening window | [ ] |
| Specific question the test should answer | [ ] |
| Application owner who approves the test | [ ] |
| Infrastructure/CDN owner and provider policy checked | [ ] |
| Tester, on-call observer and person empowered to stop | [ ] |
| Approved date, local time zone, duration and notification channel | [ ] |
| Cost/quota review and alert owner | [ ] |

## 2. Exact target scope

| Journey or URL pattern | Owned by | Included or excluded | Data used | Reason |
|---|---|---|---|---|
| Public event landing page | [ ] | [ ] | Synthetic | [ ] |
| Schedule or asset retrieval | [ ] | [ ] | Synthetic | [ ] |
| Registration form | [ ] | [ ] | Non-real test records only if approved | [ ] |
| Ticketing platform or hosted checkout | Third party / verify | Exclude unless separately authorized | None by default | [ ] |
| Email, SMS, payment, analytics, CAPTCHA or bot defense | Third party / verify | Exclude or explicitly coordinate | None by default | [ ] |

Record hostnames and environment explicitly: [ ]. A link from an owned page to a supplier service does not grant permission to test that service.

## 3. Bounded traffic profile

| Phase | Authorized request/user pattern | Duration | Maximum | Monitor confirms before next phase |
|---|---|---|---|---|
| Baseline | [ ] | [ ] | [ ] | [ ] |
| Gradual ramp | [ ] | [ ] | [ ] | [ ] |
| Expected on-sale shape | [ ] | [ ] | [ ] | [ ] |
| Recovery / ramp down | [ ] | [ ] | [ ] | [ ] |

Derive targets from the event forecast, observed analytics and provider capacity. Do not copy a universal concurrency value from a generic article. Keep the test low enough to stop safely and distinguish simulated traffic from real attendees in monitoring.

## 4. Stop conditions and response

| Signal | Event-specific stop condition | Who watches | Stop action and contact |
|---|---|---|---|
| Guest-facing errors or degraded registration | [ ] | [ ] | [ ] |
| Sustained latency or failed requests | [ ] | [ ] | [ ] |
| Provider throttle, WAF or quota alert | [ ] | [ ] | [ ] |
| Unexpected charges or downstream effects | [ ] | [ ] | [ ] |
| Real sale or guest support incident | [ ] | [ ] | [ ] |

Have a manual stop route even if the chosen tool supports automatic abort thresholds. If a stop condition occurs, end the traffic, tell the incident owner, preserve timestamps and do not simply rerun at a higher rate.

## 5. Result and next decision

| Evidence | Observation |
|---|---|
| Actual traffic shape and times | [ ] |
| Error rate and latency by tested journey | [ ] |
| Backend, CDN, database and third-party symptoms | [ ] |
| Difference from real attendee behavior | [ ] |
| Cost, quotas and alerts | [ ] |
| Fix owner, due date and permitted retest | [ ] |

Result owner: [ ]. Review date: [ ]. Decision: [accept current capacity / fix and retest / change launch plan].