Skip to main content
Back to blog

Staging vs Production Load Testing: When Each Is Safe

3 min read
Loadcurl
Loadcurl
Loadcurl Team

Traffic from a load test is real. Generators open connections, hit auth, touch databases, and trip rate limits. Choosing staging vs production is a safety decision first — a metrics decision second.

Default: staging​

Use staging when you want to answer:

  • Can we sustain target RPS?
  • Do p95/p99 stay inside SLOs?
  • What breaks first as we climb the ladder?

Requirements for useful staging:

  • Sized similarly to production (or known scale factor)
  • Realistic data shapes and auth paths
  • Observability (CPU, DB, queues, errors)
  • A hostname you can verify in Loadcurl

Verify staging.example.com (or the staging apex) under Domains, then run New test against that host only.

When production load testing can be justified​

Production game days make sense when:

  • Staging cannot reproduce production dependencies or traffic paths
  • You need to validate autoscaling, CDN, or edge behavior for real
  • The business accepts controlled risk with on-call coverage

Treat it as an incident rehearsal, not a casual click of Start.

Production rules of engagement​

  1. Permission — only systems you own / are allowed to test
  2. Domain verification — proves control; does not make load “safe”
  3. Modest RPS first — climb a ladder; do not jump to peak
  4. Ramp-up — avoid cliff-edge traffic from RPS = 0
  5. Abort criteria — max error rate, max p99, customer impact signals
  6. On-call + observability — dashboards open before Start
  7. Off-peak window — unless the goal is peak-hour realism
  8. Stop early — Loadcurl can stop a live run and release unused quota hold

Staging pitfalls that create false confidence​

  • Tiny staging DB that never saturates like prod
  • Disabled rate limits or auth shortcuts
  • Synthetic payloads that skip hot queries
  • No cache warming difference documented

Document gaps so nobody claims “staging survived 2k RPS” as a production guarantee without a scale factor.

How Loadcurl enforces a baseline of responsibility​

  • Only verified hosts (or their subdomains) can be targeted
  • Personal: 1 domain; company: up to 10 (handy for staging + API + app)
  • Quota hold duration × RPS limits accidental multi-hour blasts without plan capacity

Still: you choose the URL and the RPS. Prefer staging in the composer by default.

Decision cheat sheet​

GoalEnvironment
Feature capacity / regressionStaging
Find breaking point (stress)Staging
Autoscale / multi-AZ realismProduction game day
Marketing “we tested prod at peak”Only with formal game day
Browse all

  • How-to guides · curl

    How to Perform Load Testing Using cURL

    Learn how curl fits into API load testing — from single-request debugging to pasting curl into a cloud load dashboard for RPS-based runs and reports.

  • How-to guides · GraphQL

    Load Testing GraphQL over HTTP

    How to load test GraphQL APIs over HTTP with POST, headers, and JSON bodies — what works in Loadcurl today, and pitfalls unique to GraphQL.

  • How-to guides · authentication

    How to Load Test Authenticated APIs (Safely)

    Load test authenticated HTTP APIs without leaking secrets — staging tokens, header hygiene, rate limits, and how Loadcurl stores request credentials.