Personal workspace​

Created automatically when you register.

• You are the only member (Owner)
• Up to 1 verified domain
• Quota and billing are yours alone
• Sidebar: Dashboard, Tests, Domains, Plan, Usage, Account, Support

Ideal for solo engineers validating an API from the browser.

Company workspace​

Created when you upgrade from Account, or when you invite someone from a personal workspace.

• Roles: Owner, Admin, Member
• Up to 10 verified domains (app, API, staging, …)
• Shared request quota and plan
• Extra Organization nav for members
• Tests show as team history

Conversion is one-way. You cannot turn a company back into personal.

Side-by-side​

When to upgrade​

Upgrade when you need any of:

• Teammates to start runs or view reports without sharing a login
• Multiple verified hosts
• One shared monthly request pool and Razorpay plan
• Clear Owner/Admin checkout vs Member run access

You can upgrade and remain the only member — invites are optional.

Roles in practice​

• Owner / Admin — invite, manage domains, Razorpay checkout
• Member — run tests, view usage; cannot check out
• Invites go to email with a 7-day accept link; invitee must use that same email
• Owner cannot leave until ownership is transferred

Quota implication for teams​

Starting a test holds duration × RPS on the shared wallet. Coordinate large rehearsals on Usage so two peak runs do not collide. Unused requests still do not carry over at period end.

How to upgrade​

1. Open Account
2. Upgrade to a company
3. Enter company name → confirm
4. Invite from Organization when ready

Docs: Workspaces · Plan and usage

1. Scope​

• Critical HTTP endpoints listed (not “the whole monorepo”)
• Expected peak RPS estimated per endpoint
• Latency SLOs written (percentile + threshold + RPS context)
• Error / timeout budgets written

2. Environment​

• Staging sized meaningfully (or scale factor documented)
• Hostname verified in Loadcurl Domains
• Staging credentials only in the composer
• Production game day only if explicitly approved

3. Request realism​

• curl / Postman request matches production shape
• Auth path enabled (not a fake bypass)
• Bodies and params representative
• One endpoint per Loadcurl test (hottest first)

4. Load profile​

• Smoke run completed
• Ramp-up set (not always 0)
• Duration long enough for steady-state
• Quota hold duration × RPS fits Available
• Plan max RPS / duration sufficient

5. Observability​

• App, DB, queue, and dependency dashboards open
• On-call informed for high RPS / prod windows
• Abort criteria agreed (error %, p99, customer impact)

6. Execute the ladder​

• Baseline (~50% peak)
• Target peak load
• Optional stress on staging
• Optional soak if leak risk is high

7. Read and share​

• Throughput vs target reviewed
• Successful p95/p99 vs SLO
• 4xx/5xx/timeouts explained
• PDF downloaded and attached to launch doc
• Bottlenecks filed or fixed before go-live

8. After launch​

• Keep a short regression profile for post-deploy runs
• Revisit RPS assumptions with real traffic

Loadcurl quick path​

Register → verify domain → New test (paste curl/Postman) → set duration / ramp-up / RPS → Start → poll run → report → PDF.

Guides: Staging vs Production · Read a report · Getting started

There is no separate GraphQL protocol mode in Loadcurl today (and no gRPC/WebSocket tester). Treat GraphQL as HTTP.

What to put in the request​

Typical shape:

POST /graphql
Content-Type: application/json
Authorization: Bearer STAGE_TOKEN

{
  "query": "query HeroName { hero { name } }",
  "variables": {}
}

Validate once in Postman/curl, then paste into New test. Verify the hostname first.

GraphQL-specific pitfalls under load​

1. HTTP 200 with errors in the body​

Many GraphQL servers return 200 even when errors is populated. Your load report may show a healthy 2xx rate while clients are failing. Check response samples / request results, and monitor app-level error metrics.

2. Over-fetching hides the real hotspot​

A single “simple” query can fan out to many resolvers and services. p99 may reflect the heaviest resolver, not the gateway.

3. Persisted vs ad-hoc queries​

Ad-hoc queries stress parsing and planning differently than persisted queries in production. Match what you actually ship.

4. N+1 resolver patterns​

Load tests that only hit a tiny entity look fine until a list field explodes. Include representative list queries in a separate test.

5. Auth and complexity limits​

Complexity/depth limiters and per-token rate limits often show up as 429 or GraphQL errors before CPU saturates.

How to structure Loadcurl tests​

Because each test is one HTTP request under a load profile:

• Test the hottest query alone first
• Add a second test for a mutation path
• Use smoke → load ladders like REST
• Compare PDFs when you change dataloader / caching / indexes

Pass criteria ideas​

• Target RPS sustained
• Gateway + resolver p95/p99 under budget (from APM)
• Transport error/timeout rates low
• Application-level GraphQL error rate under budget (not only HTTP 2xx)

Related reading​

• How to Load Test from Postman
• How to Identify API Bottlenecks
• FAQ — what you can test

Total attempt budget ≈ duration × target RPS

Plus enough steady-state time after ramp-up for percentiles to mean something.

The budget formula​

Loadcurl holds duration × RPS (minimum 1) at start. Examples:

Check Usage before you click Start.

Why short runs mislead​

A 20-second blast may never leave warmup. p99 from a few hundred requests is noisy — especially with ramp-up 0.

Rules of thumb:

• Prefer several minutes at target RPS for load SLOs
• Use ramp-up so the hold window is mostly steady
• Re-run once if the first report looks like a cold-start artifact

Percentiles need samples​

Rough intuition: to talk about p99 with any confidence, you want thousands of successful requests in the measurement window — not dozens. Higher RPS reaches that sooner; lower RPS needs more duration.

Separate smoke from proof​

Do not spend a Scale-plan hold debugging a wrong header — smoke first.

Plan caps still apply​

Quota is one limit. Max RPS and max duration on your plan also cap the composer. Free plans intentionally keep rehearsals smaller.

Practical recipe​

1. Smoke: ~1k–2k request hold
2. Baseline: ~25–50% of peak for 5 minutes
3. Peak load: full target for 10 minutes with ramp-up
4. Compare PDFs; only then consider stress/soak

Details on holds: Request Quota Explained · Billing docs

What p99 is telling you​

p99 is the latency threshold that 99% of requests beat. Spikes usually mean queueing delay or occasional expensive work, not that every request got slower.

Pair it with error/timeout rates and successful-vs-all scopes in the report.

Frequent root causes​

1. Thread / connection pool saturation​

Requests wait for a DB, Redis, or HTTP client connection. CPU may look calm while p99 climbs.

2. Database locks and hot rows​

Contended updates, missing indexes, or single-row hotspots create long tails under RPS.

3. Garbage collection and runtime pauses​

Language runtimes under allocation pressure add multi-hundred-millisecond stalls visible at p99 before p50 moves.

4. Downstream dependency latency​

Your handler is “fine” but a billing, search, or auth dependency saturates. Fan-out multiplies the effect.

5. Synchronous logging / tracing overload​

Chatty logs or heavy trace export at high RPS steal tail latency.

6. Cold path vs warm path​

Cache misses, first-request JIT, or per-tenant cold starts create rare slow calls — classic p99 fuel.

7. Retries amplifying load​

Client timeouts trigger retries, which raise RPS and create more timeouts — a feedback loop.

How a load report points the way​

In Loadcurl-style reports:

• p50 flat, p99 rising during hold → saturation building
• Achieved RPS below target → system cannot accept work fast enough
• Timeouts up → somewhere exceeded budgets
• 5xx up → hard failures, not just slowness
• Successful p99 OK, all p99 bad → failures dominate the mixed distribution

Then confirm with DB pool metrics, lock times, and dependency dashboards. Playbook: How to Identify API Bottlenecks.

What usually does not fix p99​

• Raising timeouts (hides queueing)
• Adding app replicas when the DB is the limiter
• Averaging away the tail in executive slides

Related reading​

• What Is p95 and p99 Latency?
• How to Set Latency SLOs
• Report docs

Prefer staging credentials​

• Issue tokens scoped to staging
• Avoid production admin keys in the composer
• Rotate anything pasted into tickets, chat, or screenshots
• Use short-lived tokens when your IdP allows

Loadcurl stores headers and bodies you enter so it can run the test and build the report. Data is sent over TLS. Prefer staging tokens — see the product FAQ and Privacy Policy for how account data is handled.

Make auth realistic, not theatrical​

Under load you want the same auth path users hit:

• Real JWT validation / introspection cost
• Same required headers and content types
• Same failure mode when tokens expire mid-run

Avoid “auth disabled on staging” if you claim production readiness from that run.

Token expiry during long runs​

Soak and long load tests can outlive access tokens.

Options:

• Use a longer-lived staging token for the rehearsal window
• Keep duration inside token lifetime
• Re-run shorter holds rather than one multi-hour authenticated blast with a dying token

(Loadcurl runs one static request definition per test — it does not refresh OAuth for you mid-run today.)

Rate limits and 429s​

Authenticated endpoints often have stricter per-token or per-user limits. Under high RPS you may be measuring the limiter, not the handler.

Interpret 429s explicitly:

• Expected protection → adjust RPS or use a load-test-aware limit on staging
• Accidental low limit → fix config before blaming app CPU

Header hygiene checklist​

• No production secrets in Postman exports you paste
• Strip cookies you do not need
• Do not put PII in JSON bodies “just to be realistic” if synthetic IDs work
• Verify only hosts you own (domain verification)

Workflow in Loadcurl​

1. Verify staging domain
2. Prove one authenticated call in Postman/curl
3. Paste into New test (headers included)
4. Start with a smoke RPS first
5. Climb to target; read 401/403/429 vs 5xx carefully in the report

Related reading​

• Staging vs Production Load Testing
• How to Load Test from Postman
• Loadcurl FAQ

Smoke test​

Question: Does the path work under a little traffic?

• Low RPS (often 5–20)
• Short duration (1–3 minutes)
• Ramp-up optional / small
• Watch for 4xx/5xx and obvious timeouts

Use after changing the Postman/curl request, auth headers, or domain — before spending a large duration × RPS hold.

Load test​

Question: Can we sustain expected peak with acceptable p95/p99 and errors?

• Target RPS from traffic math
• Minutes-long hold after ramp-up
• Pass/fail criteria written first

This is Loadcurl’s default job: target RPS, ramp-up, duration, then a report. See Load vs Stress vs Performance Testing.

Soak (endurance) test​

Question: Does performance drift over time — leaks, saturation, disk, connection exhaustion?

• Moderate RPS (often below peak)
• Long duration (tens of minutes to hours — within plan max duration)
• Watch p99 and error rate over time, not only averages

Soak is still a load profile — same composer — with different intent and patience. Check quota hold first; long × RPS gets expensive.

Stress (for contrast)​

Question: Where does it break above peak? Prefer staging. Not the same as soak or smoke.

Quick comparison​

Suggested Loadcurl sequences​

1. Smoke at 10 RPS × 120s
2. Load at target × 600s with 60s ramp-up
3. Optional soak at 50% peak × as long as plan + quota allow
4. Optional stress on staging only

Stop early if the smoke fails — do not burn Growth-plan quota on a bad Authorization header.

Related reading​

• What Is Ramp-Up in Load Testing?
• Request Quota Explained
• Pre-Launch Checklist

Pick the user-visible interaction​

Examples:

• POST /checkout p95 < 300 ms at 150 RPS
• GET /search p99 < 500 ms at 400 RPS
• Auth token exchange p95 < 150 ms at expected peak

Write the endpoint, percentile, threshold, and RPS context together. An SLO without a load context is incomplete.

Prefer p95 or p99 over the mean​

Averages hide tails. Clients abandon and retry on the tail. Background: What Is p95 and p99 Latency?.

Common patterns:

• User-facing read APIs: p95
• Payments / auth / fan-out critical paths: p99
• Internal mesh hops: tighter budgets so end-to-end still fits

Separate correctness from speed​

A latency SLO should sit next to an availability / error objective:

• Success rate ≥ 99.5% at the same RPS profile
• Timeout rate under a small budget

Fast 500s are not success. Loadcurl reports make you look at both status mix and percentiles.

Derive thresholds from product reality​

Sources, in order of honesty:

1. Current production percentiles at known RPS (APM)
2. Competitor/UX research budgets
3. Dependency math (your p99 must fit inside the caller’s timeout)

Then add headroom for regressions. Do not invent “50 ms p99 at 10k RPS” if production never saw that load.

Turn SLOs into load-test pass criteria​

Before Start in Loadcurl:

Duration 600s, ramp-up 60s, target 150 RPS. Pass if successful p95 < 300 ms, errors < 0.5%, average RPS within 10% of target.

After the run, read the report scopes (successful vs all) so timeouts do not silently invent a fake p99. Guide: How to Read an API Load Test Report.

Keep SLOs testable​

• One primary percentile per endpoint
• Same load profile when comparing releases
• Document staging vs production scale factor
• Re-run after risky deploys; attach PDF

Anti-patterns​

• SLO on average latency only
• SLO without RPS or concurrency context
• Tightening timeouts instead of fixing queues
• Different payloads every run so trends are meaningless

Related reading​

• API Performance Testing Best Practices
• How to Identify API Bottlenecks
• Tests and reports docs

This is an honest comparison — including what Loadcurl does not do yet.

What each class of tool optimizes for​

Where a dashboard wins​

• No install — no local workers, Docker swarm, or agent fleet for day-one tests
• Curl/Postman paste — reuse the request you already debugged
• Ownership gate — domain verification before traffic
• Shared workspace — tests, domains, quota, and billing in one org
• Polled live run + report — latency percentiles, throughput vs target, HTTP outcomes

For staging rehearsals and pre-launch checks on a single endpoint, that loop is often enough.

Where scripted tools still win​

Be frank with stakeholders:

• Multi-step user journeys (login → browse → checkout) — Loadcurl is one HTTP request per test today
• CI pipelines / GitOps — no first-class CLI/CI integration in the current product
• Custom protocols beyond HTTP (gRPC, WebSocket-native flows) — not supported yet
• Exotic traffic shapes you want fully coded and reviewed like application code

If those are hard requirements, keep k6/Locust/JMeter (or use both: scripts for journeys, dashboard for hotspot endpoints).

Ops cost is part of the comparison​

Self-hosted generators mean you own:

• Machine sizing and regions
• Result storage and report formatting
• Team access control
• Preventing accidental tests against the wrong host

Loadcurl trades that ops surface for plan caps and request quota (duration × RPS holds).

A practical decision rule​

Choose Loadcurl-style dashboard when:

• You need an RPS answer this afternoon
• The critical path is one or a few HTTP endpoints
• Engineers live in Postman/curl already
• You want cloud generators without maintaining them

Choose k6 / Locust / JMeter when:

• Scenarios must be code-reviewed scripts
• CI must gate merges on performance
• Journeys span many steps or protocols

Hybrid workflow many teams use​

1. Debug in Postman/curl
2. Paste into Loadcurl for a fast cloud RPS hold + PDF
3. Promote complex journeys to k6 later if needed

See Cloud-Based vs Local Load Testing and the product intro.

Hold ≈ duration (seconds) × target RPS (minimum 1)

Understanding that formula prevents failed starts and “where did my quota go?” moments.

The four quota buckets​

You see the same wallet on the header quota chip, Dashboard, and Usage (/wallet). Plan (/billing) is where you recharge or upgrade via Razorpay.

Why multiply duration × RPS?​

A test configured for 200 RPS over 600 seconds can attempt up to about 120,000 requests. Loadcurl holds that amount up front so two teammates cannot over-commit the same monthly pool.

If available is too low, start is blocked and you get an insufficient quota error.

What happens after the run?​

• When the report is ready, actual hits are consumed and unused hold is returned
• Stop on a live run (or a failed run without a usable report) releases the hold
• Hold states you may see on the run page: Reserved / Consumed / Returned (HELD, SETTLED, or RELEASED)

Worked examples​

Smoke tests are cheap. Launch rehearsals are not — check Usage first.

What quota is not​

• Not a substitute for max RPS and max duration plan caps on the composer
• Not carried over when the billing period ends — unused requests expire
• Not per-user in a company workspace — the team shares one pool

Personal quota stays in the personal workspace until you convert to a company.

Practical tips​

1. Estimate hold before Start: duration × RPS
2. Prefer shorter smokes while debugging the request shape
3. Stop early if the run is clearly invalid — release unused hold
4. Recharge or upgrade on Plan when Available is tight
5. Members can view Usage; Owner/Admin check out

Related reading​

• How Many Requests for a Meaningful Load Test?
• Personal vs Team Workspace
• Plan and usage docs

In Loadcurl, ramp-up is configured in seconds. 0 means start at full target RPS immediately.

The three knobs​

Example: duration 600s, ramp-up 60s, target 200 RPS → roughly one minute of climb, then about nine minutes near peak (exact shape depends on the generator schedule).

Why ramp-up matters​

Starting at full blast mixes different failure modes:

• Cold caches and empty connection pools
• Autoscalers still waking up
• JIT / runtime warmup
• Sudden lock or queue shocks

A short ramp-up lets the system enter a steady state so p95/p99 during the hold reflect capacity — not just cold-start drama.

Choosing a ramp-up​

Practical starting points:

• Smoke / debug: 0–15 seconds
• Normal load test: 30–120 seconds
• Higher RPS or autoscale validation: 60–180+ seconds

If your pass criteria care about steady-state latency, either use a non-zero ramp-up or ignore the first portion of the run when comparing percentiles.

Ramp-up is not duration​

Teams sometimes set a long duration and forget ramp-up — or set ramp-up equal to duration and never reach a stable hold. Prefer:

1. Enough ramp to warm
2. Enough remaining duration to measure at target RPS

See How Many Requests Do I Need for a Meaningful Load Test?.

Quota impact​

Loadcurl still places a hold of roughly duration × RPS when you start (minimum 1). Ramp-up does not shrink that reservation formula — plan Usage accordingly.

Common mistakes​

• Ramp-up 0 on a production game day
• Comparing p99 from a zero-ramp run to a 2-minute-ramp run without noting the difference
• Ramp longer than the whole test, leaving no steady hold

In the product​

On New test, set duration, ramp-up, and target RPS (capped by plan). Paste curl / Postman or fill the composer, verify the domain, then start.

Docs: Getting started · Core concepts

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​

Related reading​

• How to Verify a Domain for Load Testing
• What Is Ramp-Up in Load Testing?
• Pre-Launch Load Testing Checklist
• Loadcurl FAQ

Where the report lives​

After Start test, open the run from Dashboard or Tests. The run page polls about every 3 seconds (no websockets). Timeline: Created → Resources → Testing → Report (or failed / stopped).

While the report is calculating you may see a processing state — wait. There is no letter grade and no public share link. Download a PDF or keep teammates in the same workspace.

Start with the highlights​

Most reports surface:

• Success rate
• Total requests
• Average latency
• Average RPS

Use these as a headline, not the verdict. Dig into throughput, latency percentiles, and status mix next.

Request summary: correctness under load​

Look for counts and rates such as:

• Total, completed, successful, failed
• Timeouts and transport errors
• HTTP 2xx / 3xx / 4xx / 5xx
• Success, completion, failure, and timeout rates

Ask:

• Are failures 5xx (server) or 4xx (client/auth/validation)?
• Are timeouts rising — a sign of saturation or too-tight budgets?
• Is “success rate” high while p99 is terrible? Users still feel pain.

Throughput: did you actually hit the target?​

Compare:

• Target RPS (what you configured)
• Average / peak / minimum RPS achieved
• Successful and completed RPS
• RPS vs target (achievement)
• Response bytes and bytes/sec (average and peak)

Interpretation tips:

• Average RPS ≈ target, healthy errors → capacity looks good for that profile
• Average RPS ≪ target → the API, network, or errors prevented the generators from sustaining load
• Peak much higher than average with a bad p99 → unstable under hold

Latency: read percentiles by scope​

Reports often group latency for all, completed, and successful requests:

• Min, average, max, standard deviation
• p50, p75, p90, p95, p99

Prefer p95 / p99 on successful requests for SLO conversations. If “all” looks much worse than “successful,” failures and timeouts are dominating the tail.

Deep dive: What Is p95 and p99 Latency?.

Request results table​

Paginated per-request outcomes (Completed, Timeout, Error) with status codes help you spot patterns — a burst of 429s, a dependency 502, or slow payloads. Expand a row when body/error detail is present.

Request hold (quota context)​

On the live run you may also see Reserved / Consumed / Returned for the quota hold (duration × RPS). Stopping early releases unused hold. That is billing mechanics — not a performance metric — but it explains why Usage changed.

A simple pass/fail script​

Before the run, write criteria. After the report:

1. Throughput within ~X% of target?
2. Successful p95 / p99 under budget?
3. Error + timeout rates under threshold?
4. Any surprise 429/5xx pattern?

If no → open How to Identify API Bottlenecks and re-run the same profile after one change.

Share the PDF​

Download PDF once the report is ready. Attach it to the launch checklist or incident doc so product and infra argue from the same numbers.

Product reference: Tests and reports.

Why verification exists​

Without it, any account could aim cloud generators at someone else’s API. Verification proves you control the DNS or the HTTP origin for that host.

A test URL is allowed when its hostname equals a verified domain or is a subdomain of one. Example: verifying example.com also covers api.example.com and staging.example.com.

Where to do it​

In the dashboard: Domains (/organization/domains).

• Any member can view domains
• Owner and Admin can add, verify, and remove

Caps​

The cap counts pending, failed, and verified rows.

Method A: DNS TXT (preferred)​

Add a TXT record:

The exact token is shown in the app when you add the domain. DNS can take a few minutes to propagate — then click Verify again.

Choose DNS TXT when: you control DNS, want a durable proof, or the app sits behind a CDN that makes file checks awkward.

Method B: HTTP file​

Serve this path over HTTPS (HTTP is tried if HTTPS fails):

https://{your-domain}/.well-known/loadcurl-verification.txt

The body must be the challenge token. Redirects are rejected. The check times out after a few seconds.

Choose HTTP file when: you can deploy a static file quickly but DNS changes are slow (or owned by another team).

Challenge expiry and conflicts​

• Pending challenges last 7 days. If expired, add the domain again for a new token.
• You cannot verify a hostname another organization already has verified.
• Statuses: Pending, Verified, Failed.

What you can enter​

• A public DNS hostname (FQDN)
• Not an IP address, port, wildcard, localhost, or platform apex names like vercel.app

Paste a full URL if you want — Loadcurl keeps the host only.

Recommended setup for teams​

1. Verify the staging apex or API host first
2. Upgrade to a company workspace if you need multiple hosts (app, API, staging) — up to 10
3. Keep production verification only if you run planned game days
4. Document which method you used in the runbook

Verification is not a safety guarantee​

Proving ownership does not make unlimited production load safe. Prefer staging, use ramp-up, and set abort criteria. See Staging vs Production Load Testing.

After verification​

Open New test, compose or paste curl / Postman, set duration / ramp-up / target RPS, and start. Only verified hosts (and their subdomains) are accepted.

Full product steps: docs — Verify a domain.

Why Postman alone is not enough​

Collection Runner and simple scripts can fire many requests, but they rarely give you:

• Precise target RPS with ramp-up
• Clean p95 / p99 under sustained hold
• Throughput vs target and HTTP outcome mix in one report
• Cloud generators that are not capped by your laptop

Treat Postman as the authoring tool. Treat a load dashboard as the measurement tool.

Step 1: Make the request correct in Postman​

On staging (preferred):

1. Method, URL, query params, headers, and JSON body match production shape
2. Auth works (Bearer, API key, etc.)
3. You get the expected status code and body
4. Secrets are staging-scoped — not production admin tokens

Save that request. You will reuse the same shape under load.

Step 2: Get a pasteable snippet​

Depending on your Postman version:

• Code snippet → cURL from the request, or
• Copy as curl / export the HTTP details your team already shares

Loadcurl’s composer accepts curl / Postman paste and fills method, URL, headers, params, and body for you. You can also fill those fields manually on New test.

Step 3: Verify the hostname in Loadcurl​

Loadcurl only sends traffic to hosts your workspace has verified. Open Domains, add the hostname from your Postman URL (or paste the full URL — only the host is kept), then verify with DNS TXT or HTTP file.

Verifying example.com also covers api.example.com. Personal workspaces: 1 domain. Company: up to 10.

Details: Verify a domain.

Step 4: Paste into New test and set the load profile​

1. Sign in at app.loadcurl.com
2. Open New test
3. Paste the Postman/curl snippet (or fill the form)
4. Set duration, ramp-up, and target RPS within your plan caps
5. Start — the app checks remaining quota first (duration × RPS hold)

Each Loadcurl test is one HTTP request repeated under that profile (no multi-step Postman collections yet).

Step 5: Watch the run and read the report​

The run page polls about every 3 seconds through pending → provisioned → running. When it finishes you get:

• Request summary (2xx–5xx, timeouts, success rates)
• Throughput vs target RPS
• Latency percentiles (p50–p99), often by scope (all / completed / successful)
• PDF download for sharing

See How to Read an API Load Test Report.

Postman collection tips that transfer cleanly​

• Prefer environment variables resolved before you copy curl (so the pasted URL is concrete)
• Avoid Postman-only pre-request scripts that mint tokens unless you also set the final header in the paste
• Keep body JSON identical to what you validated
• Name the Loadcurl test after the Postman request so history stays searchable

Common mistakes​

• Pasting a production URL you have not verified (or should not load-test)
• Skipping ramp-up after a gentle Postman check
• Judging success only by Collection Runner “pass” counts instead of p95/p99
• Forgetting quota: a 600s × 200 RPS run holds 120,000 requests

Related guides​

• How to Perform Load Testing Using cURL
• How to Calculate RPS
• Getting started

Local load testing​

Local means traffic originates from your machine or a self-managed VM in your network (k6 on a laptop, Locust on a bastion, shell parallel curl, etc.).

Strengths​

• Fast feedback while debugging a single endpoint
• No extra SaaS account for a quick experiment
• Full control over the generator process
• Easy to poke private APIs on a VPN

Weaknesses​

• Laptop CPU, Wi‑Fi, and file descriptors cap achievable RPS
• Office networks and VPNs distort latency
• Hard to produce clean, repeatable p95/p99 at scale
• You own patching, scaling, and multi-machine coordination
• Easy to accidentally DDoS a shared staging box from “just a script”

Local is excellent for functional confidence and small smoke loads. It is a weak source of truth for launch capacity.

Cloud-based load testing​

Cloud-based means managed generators run in provider infrastructure. You configure the HTTP request and load profile in a UI or API; workers elsewhere send traffic.

Strengths​

• Higher sustained RPS without turning your Mac into a heater
• More stable generator capacity and networking
• Dashboards, reports, and PDF export without building them
• Team sharing of tests, domains, and quota
• Less ops work than maintaining your own load cluster

Weaknesses​

• Requires network path from cloud generators to your target (public staging or allowed ingress)
• Usage is often gated by plan limits / request quota
• You must still instrument your systems to find bottlenecks

Accuracy: where latency is measured​

Latency always includes the path from generator → target.

• Local over VPN can look worse than real users
• Cloud generators may sit closer to (or farther from) your region than your users
• Absolute numbers matter less than trends across comparable runs

Keep the generator location consistent when comparing releases.

Ops and safety​

When to use which​

Use local when:

• Validating curl/auth against staging
• Reproducing a single bug
• Hitting a private endpoint only reachable on VPN
• Running tiny smokes (< tens of RPS)

Use cloud when:

• Validating peak RPS and p95/p99 for launch
• You need repeatable reports for stakeholders
• Multiple engineers share profiles and history
• Local hardware or network is the limiter

Many teams do both: curl locally, then paste the same curl into a cloud run.

How Loadcurl approaches this​

Loadcurl is cloud-based by design: no CLI or local workers to install. You verify a hostname, compose a request or paste curl / Postman, set duration, ramp-up, and target RPS, then start. Generators run in the cloud; the run page polls live status; you get a report with latency percentiles, throughput vs target, and HTTP outcomes.

That matches the “author with curl, execute in the cloud” workflow described in How to Perform Load Testing Using cURL.

Get started: docs intro · app registration

Bottom line​

Local scripts are a scalpel. Cloud load testing is a measuring bench. Use the scalpel to shape the request; use the bench to prove capacity.

Use the report as a symptom list, then confirm with infrastructure signals.

Start with four report signals​

1. Throughput vs target RPS​

If achieved RPS stays well below target while the generators are healthy, the server side is refusing or delaying work — saturation, rate limits, or connection refusal.

If achieved RPS matches target but latency is terrible, you are successfully delivering pain at the requested rate.

2. p95 / p99 shape over time​

• Immediate high p99 → likely misconfig, cold dependency, or too-high starting RPS
• Rising p99 during a hold → queues filling, pools exhausting, GC, lock contention
• p50 flat, p99 rising → classic tail saturation

See What Is p95 and p99 Latency?.

3. HTTP status mix​

• 429 — limiter or WAF; may be intentional protection
• 5xx — application or upstream failure under load
• Timeouts — somewhere in the chain exceeded client or gateway budgets

4. Successful vs all latency scopes​

If successful latency looks fine but “all” looks awful, failures/timeouts dominate the story. Fix errors before chasing micro-optimizations on the happy path.

Map symptoms to likely layers​

A debugging loop that works​

1. Reproduce at the lowest RPS that shows the symptom
2. Capture report + app/DB dashboards for the same time window
3. Hypothesize one layer
4. Change one thing (index, pool size, cache, instance count)
5. Re-run the same profile and compare PDFs

Do not climb to 10k RPS while debugging a failure that appears at 500.

Application-level checks​

• Slow query logs during the run
• Contended locks or unique constraints on hot keys
• N+1 calls hidden behind one API endpoint
• Oversized payloads and unnecessary JSON work
• Chatty logging or tracing at high RPS

Dependency checks​

Fan-out multiplies load. If one user request triggers four internal calls, your dependency may see far more RPS than the edge. Load test the hotspot and watch the dependency’s saturation metrics.

Client-side false bottlenecks​

Before blaming the API:

• Confirm generators actually reached target RPS
• Rule out laptop/network limits for local tools
• Prefer cloud generators for serious profiles (comparison)

Using Loadcurl in the loop​

Run the same New test profile repeatedly: identical curl, RPS, ramp-up, and duration. Compare latency percentiles, throughput achievement, and HTTP outcomes across PDFs while you change infra. The run page’s polled status helps you see when provisioning vs testing vs report phases occur — useful when correlating with cloud metrics.

Details: report card docs.

Bottleneck anti-patterns​

• Scaling app pods when the DB is the limiter
• Raising timeouts to “fix” p99 (hides the queue)
• Disabling rate limits in production to pass a test
• Tuning without a fixed RPS profile for comparison

Related reading​

• How to Test an API for 10,000 RPS
• API Performance Testing Best Practices
• Common Mistakes

Use this checklist as your default playbook.

1. Define success before you generate traffic​

Write pass criteria in one line:

At 200 RPS for 10 minutes with 60s ramp-up, successful p95 < 250 ms, errors < 0.5%, timeouts < 0.1%.

Without this, every run becomes a debate.

2. Prefer staging that mirrors production​

Match instance sizes, connection limits, cache configuration, and auth paths as closely as you can. Document gaps so you do not over-claim.

3. Author realistic HTTP requests​

Start from production traces or a known-good curl / Postman snippet. Include required headers and a representative JSON body. Avoid empty happy paths that skip validation or DB work.

4. Think in RPS, ramp-up, and duration​

• RPS — arrival rate you care about
• Ramp-up — time to reach that rate
• Duration — hold long enough to exit warmup

Calculate RPS from traffic, not vibes — see How to Calculate RPS.

5. Climb a ladder​

Smoke → baseline → target → optional stress. Stop when SLOs fail; fix bottlenecks; continue. Jumping straight to peak hides the first breaking layer.

6. Watch percentiles and errors together​

Track p95/p99 on successful responses and error/timeout rates. Hitting target throughput with rising 5xx is not a pass. Background: p95 and p99.

7. Keep observability open during the run​

Dashboards for CPU, memory, DB connections, lock waits, queue depth, and downstream latency turn “it got slow” into “the pool saturated at 2k RPS.”

8. Change one variable between comparisons​

Same request, same RPS profile, one code or infra change. Export PDFs so reviews share the same artifact.

9. Verify ownership and respect safety​

Only test hosts you control. Use domain verification. Prefer staging. Coordinate production game days. Traffic is real.

10. Re-run after meaningful deploys​

A launch-week hero run goes stale. Keep a short regression profile in the team workspace and re-run when risk is high.

11. Separate Plan capacity from vanity peaks​

Know your tool and plan limits (max RPS, duration, monthly request quota). In Loadcurl, a start holds roughly duration × RPS. Check Usage before large rehearsals.

12. Share results in the language of the product​

Translate metrics for stakeholders: “We can sustain expected launch peak with p95 under budget” beats “p99 was 412.”

A minimal recurring profile​

Store the curl, the criteria, and the last PDF next to the service runbook.

How Loadcurl supports the practice​

Loadcurl keeps the loop tight: verify domain → paste curl / compose request → set RPS profile → poll live run → read latency/throughput report → export PDF. Personal workspaces work for solo engineers; company workspaces share tests, domains, and quota.

Docs: getting started, report card.

Related reading​

• Common API Performance Testing Mistakes
• How to Identify API Bottlenecks
• Load vs Stress vs Performance Testing

Here is how to use curl the right way: debug with it, then scale with a proper load profile.

What curl is good at​

• Reproducing a single failing request
• Confirming auth headers and status codes
• Timing one call with -w / -o
• Exporting a canonical request teammates can paste

Example:

curl -sS -X POST 'https://api.example.com/v1/orders' \
  -H 'Authorization: Bearer TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"sku":"sku_123","qty":1}'

What curl is bad at (for load)​

Naive loops like for i in {1..1000}; do curl ...; done are not load tests:

• They are usually sequential, not concurrent
• They do not control RPS precisely
• They skew latency with client overhead
• They rarely produce p95/p99 or throughput reports
• Your laptop becomes the bottleneck quickly

Shell parallelism (xargs -P, background jobs) is still a rough hammer — fine for a smoke blast, weak for capacity claims.

A practical workflow: curl → load test​

1. Perfect one request with curl​

Make sure the call returns the expected status and body on staging. Fix auth, headers, and JSON first.

2. Capture the curl (or Postman) snippet​

Keep it as the source of truth for the request shape.

3. Paste into a load testing dashboard​

Tools like Loadcurl accept curl / Postman paste into the composer, then let you set:

• Target RPS
• Ramp-up
• Duration

Cloud generators send the traffic; you are not installing workers. You must verify the domain before runs can target that host.

4. Read percentiles and HTTP outcomes​

Judge the run on p95/p99, achieved RPS vs target, and error/timeout rates — not on how fast your shell loop felt.

Timing a single request with curl​

For quick local checks:

curl -sS -o /dev/null -w 'time_total=%{time_total}\nhttp_code=%{http_code}\n' \
  'https://staging.example.com/health'

Useful for debugging. Not a substitute for a multi-minute RPS hold.

Security and safety​

• Prefer staging tokens in curl history and shared snippets
• Do not load test hosts you do not own
• Strip secrets before pasting into tickets; rotate if leaked
• Ramp up; production traffic is real

Curl + Loadcurl in practice​

1. Register at app.loadcurl.com
2. Verify your domain (docs)
3. Open New test and paste your curl
4. Set RPS, ramp-up, duration
5. Start — the run page polls live status about every 3 seconds
6. Download the report PDF when finished

This keeps curl as the authoring format while cloud infrastructure handles concurrency and reporting.

When to stay local vs go cloud​

Stay local for functional curl debugging. Move to cloud generators when you need sustained RPS, clean percentiles, and isolation from laptop limits — covered in Cloud-Based vs Local Load Testing.

Related guides​

• What Is API Load Testing?
• How to Calculate RPS
• Getting started

Percentiles in one sentence​

If you sort all request latencies from fastest to slowest:

• p50 (median) — half of requests were faster than this
• p95 — 95% were faster; only 5% were slower
• p99 — 99% were faster; only 1% were slower

So a p95 of 200 ms means most traffic finished within 200 ms, while a small slice took longer.

Why averages fail​

Suppose 99 requests take 50 ms and one takes 5,000 ms. The average is ~100 ms — sounds fine. The p99 is 5,000 ms — clients are timing out.

Retries make this worse: slow calls spawn more calls, which raise load and create more slow calls.

Which percentile should you SLO on?​

Common patterns:

• User-facing APIs: p95 or p99 against a budget (e.g. p95 < 300 ms)
• Internal high-QPS services: often p99, because rare stalls still cascade
• Batch / async: sometimes p95 is enough

Pick one primary percentile and stick to it across reports so trends are comparable.

Successful vs all requests​

A subtle trap: including timeouts and failed calls in the same latency distribution as successes.

Depending on how your tool measures:

• Failed or timed-out requests may appear as very large latencies
• Or they may be excluded from latency and counted only in error metrics

Loadcurl reports latency with scopes such as all, completed, and successful — compare them. If “all” p99 blows up while “successful” looks fine, you may have a timeout / error problem rather than a slow-happy-path problem.

How tails form under load​

p99 often rises before p50 when:

• Thread or connection pools saturate
• GC pauses appear
• Lock contention increases
• Downstream dependency latency spikes
• Queueing delay builds at the load balancer

That is why climbing an RPS ladder while watching p99 catches trouble earlier than watching averages.

Reading a Loadcurl-style report​

In a typical HTTP load report you will see min, average, max, and percentiles (p50–p99), plus throughput vs target RPS and HTTP status mix.

A healthy load run at target RPS usually shows:

• Achieved throughput near target
• Stable p95/p99 after warmup
• Low error and timeout rates

A warning run shows p50 flat while p99 climbs across the hold period — classic saturation.

See the report card documentation for how Loadcurl surfaces these metrics and PDF export.

Practical tips​

• Ignore or annotate the ramp-up window when comparing percentiles
• Compare the same percentile scope between runs
• Pair latency with error rate — fast 500s are not success
• Set SLOs on the percentile your clients feel (often p95/p99), not the mean

Related reading​

• What Is API Load Testing?
• How to Identify API Bottlenecks
• Common API Performance Testing Mistakes