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 give misleading results or cause harm you did not intend.

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 with 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 picked at random.
  • 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, with 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, so there is 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. It is neither capped nor lower than expected.

See Interpreting results dos and don’ts.

Where to go next

Section titled “Where to go next”