Skip to content
MaxoPerf MaxoPerf docs

Pre-flight checklist

Use this checklist before every significant load test. Copy it into your team’s runbook, sprint ticket, or test plan and work through it top to bottom. A test that passes this checklist is far less likely to produce misleading results or cause unintended harm.

1. Authorization and safety

Section titled “1. Authorization and safety”
  • I have explicit authorization to load-test this system (owner or written sign-off).
  • The SRE / operations team has been notified of the test window and expected load.
  • The on-call rotation is aware and available during the test.
  • Third-party services (email, SMS, payment) are mocked, stubbed, or using test credentials.
  • I have a runbook for stopping the test if it causes unintended impact.
  • The test target is not a production system unless explicitly coordinated and authorized.

See Safe and ethical load testing for the full authorization checklist.

2. Test environment

Section titled “2. Test environment”
  • The test environment matches production in infrastructure shape (same cloud tier, same DB, same cache layer).
  • The environment is isolated from production traffic (no shared load balancer, no shared DB).
  • The environment has been seeded with representative data (not empty, not production PII).
  • Third-party integrations are pointing to sandbox/test endpoints.
  • The application is fully started and past its warm-up period (wait 2–5 minutes after deploy).
  • A smoke test at low VUs (1–5) has passed — no errors.

3. Load profile

Section titled “3. Load profile”
  • The VU/RPS target is derived from real production traffic data (APM, access logs, or analytics) — not arbitrary.
  • The test has a gradual ramp-up period (minimum 2–3 minutes before steady-state).
  • The test has a steady-state hold window long enough to measure (minimum 5–10 minutes).
  • Think time is configured between requests to reflect real user pacing.
  • The scenario mix reflects the real traffic distribution (read vs write vs auth flows).
  • The runner count is sufficient for the target VU count (check recommended VU capacity per runner).

See Designing realistic load and Ramp-up, think time, and pacing.

4. Test data

Section titled “4. Test data”
  • Credentials, IDs, and tokens vary per virtual user (CSV data entity attached — not hardcoded).
  • The CSV data entity has at least 1.5× as many rows as the peak VU count.
  • Secrets (API keys, passwords) are stored in MaxoPerf Secrets — not in the script file.
  • Test data is synthetic or de-identified — no real PII in the CSV or script.
  • Tokens are fetched dynamically (not copied from a manual session that will expire).
  • Data is scoped to the test environment — no risk of creating real orders, charges, or notifications.

See Test data dos and don’ts.

5. Failure criteria

Section titled “5. Failure criteria”
  • A p95 latency threshold is configured as a failure criterion (e.g. p95 < 500ms).
  • An error-rate threshold is configured as a failure criterion (e.g. error rate < 1%).
  • An early-stop criterion is configured to halt the test if errors exceed a blast-radius threshold (e.g. error rate > 10% → stop).
  • The failure criteria thresholds match the agreed SLOs for this service.

See Failure criteria pass/fail gates.

6. MaxoPerf configuration

Section titled “6. MaxoPerf configuration”
  • The test is attached to the correct project and workspace.
  • The correct engine is selected (Taurus, JMeter, k6) for this script type.
  • The correct MaxoPerf locations are selected (match the regions where your users are).
  • If using private datacenters (Outpost), the outpost runners are healthy and reachable.
  • The test file has been validated (no YAML/JMX syntax errors — check the Files tab after upload).
  • The account has sufficient quota for the planned VU count and duration.

7. Observability and alerting

Section titled “7. Observability and alerting”
  • APM / tracing is enabled on the target application and collecting data.
  • Database slow-query logging is enabled.
  • Relevant dashboards (Grafana, Datadog, etc.) are open and being monitored during the run.
  • Error-budget alerts are silenced or on a separate channel so the team is not paged for an intentional test.
  • You know the URL of the MaxoPerf run-detail page to monitor throughput, latency, and error rate in real time.

8. Post-test cleanup

Section titled “8. Post-test cleanup”
  • Test-generated records (test accounts, test orders, test bookings) will be cleaned up after the run.
  • Temporary feature flags or configuration changes made for the test are reverted after the run.
  • The SRE team is notified when the test is complete.
  • Results are saved and linked from the task/ticket for future baseline comparison.

9. Results review gate

Section titled “9. Results review gate”

Before declaring the test a pass, confirm:

  • The run status is Finished (not Failed, Aborted, or Error).
  • All failure criteria passed (green in the run overview).
  • The Runners tab shows all runners completed in a healthy state (no Degraded or Error runners).
  • The p95 and p99 latency time-series are stable across the steady-state window (no rising trend).
  • The error rate is within budget for the full steady-state window (not just the last minute).
  • The throughput (RPS) plateau matches the target load — neither capped nor lower than expected.

See Interpreting results dos and don’ts.

Where to go next

Section titled “Where to go next”