Load Testing Documentation

Quick examples

Use these examples as starting points for small controlled tests against websites and APIs you own or have permission to test.

• Website launch check: test the landing page with 50 requests, 5 requests per second, and 3 concurrent users, then review p95 latency and unexpected status codes.
• API health check: test a GET health endpoint before a release to confirm DNS, TLS, routing, and response time are behaving as expected.
• Report comparison: run the same test before and after a backend change, then compare error rate, timeout count, p95 latency, and requests per second.

Ready to try one? Open the load testing tool or review the sample report first.

Why load testing is necessary before launch

A launch is one of the worst times to discover that a page, API route, database query, or third-party dependency cannot handle real traffic. Functional testing proves that a feature works for one user. Load testing checks whether the same feature still works when many users arrive in a short window.

Even small launches can create traffic spikes. A newsletter, social post, ad campaign, app release, partner announcement, or search engine crawl can send more requests than the system normally sees. Without a baseline, teams are forced to guess whether slow pages are caused by application code, hosting limits, cache misses, database locks, external APIs, or a temporary network issue.

Problems a pre-launch test can reveal

• Pages that look fast locally but slow down when assets, fonts, scripts, and server rendering compete.
• API endpoints that work one request at a time but queue, timeout, or return 500 errors under concurrency.
• Database queries that need indexes, limits, pagination, or safer filtering before public traffic arrives.
• Rate limits from payment providers, email services, authentication systems, or other upstream APIs.
• Cold starts, low worker counts, connection pool limits, and cache behavior that only appear under traffic.

How it helps launch decisions

A load test does not need to be huge to be useful. A small controlled run can show whether the site is ready, whether a fix should happen before release, or whether the team needs a rollback plan. The report gives a shared set of facts: p95 latency, p99 latency, error rate, timeout count, status codes, and throughput.

Those numbers make conversations clearer. Instead of saying "the app feels slow," a team can say "checkout p95 is 1.8 seconds at expected launch traffic and timeouts begin when concurrency doubles." That level of detail helps engineers choose the next action, and it helps non-technical stakeholders understand the risk.

What to test before going live

1. Start with the homepage or landing page users will hit first.
2. Test important read paths such as pricing, product pages, search, dashboards, or public reports.
3. Test safe API routes that represent real user behavior.
4. Review slow paths with logs and monitoring so the report can be connected to server evidence.
5. Repeat the same scenario after fixes so the launch decision is based on improvement, not hope.

What is API load testing?

API load testing sends controlled traffic to an API endpoint and measures how the endpoint behaves while many requests arrive close together. The point is to learn whether a login route, search endpoint, checkout action, webhook, or public API stays fast and reliable at the traffic level you expect.

A useful test is focused. It does not try to create damage or surprise traffic. It asks a clear question: at this request rate and concurrency level, does the endpoint return the expected status codes, avoid timeouts, and keep response times within the range users can tolerate?

What it measures

• Latency, including average, p50, p95, and p99 response time.
• Throughput, usually shown as completed requests per second.
• Error rate, including failed status codes, timeouts, and network failures.
• Status code mix, such as 2xx success, 4xx client errors, 429 rate limits, and 5xx server errors.
• Stability, meaning whether results stay steady or degrade as traffic continues.

When to run it

Run API load tests before launch, after database or infrastructure changes, before a traffic campaign, and after performance fixes. The first report becomes a baseline, and later reports show whether the system is improving or drifting in the wrong direction.

How to test safely

1. Test only endpoints you own or have permission to test.
2. Start with low request counts and low concurrency.
3. Use sandbox users, read-only endpoints, or idempotent operations when possible.
4. Avoid repeated calls that charge cards, send emails, publish records, or damage production data.
5. Review p95 latency, p99 latency, timeout count, and status codes before increasing load.

What is p95 latency?

p95 latency is the response time that 95% of measured requests met or beat. If a report says p95 latency is 420ms, then 95% of requests finished in 420ms or less, while the slowest 5% took longer.

Percentiles matter because users do not feel the average. One user may get a quick cached response, while another waits behind a database query, cold start, external API call, or queue. p95 shows the slower edge of normal experience without letting one extreme request define the entire report.

p50, p95, and p99

• p50 is the middle request and describes a typical response.
• p95 shows the slower end of common user experience and is often a strong launch-readiness signal.
• p99 highlights rare but painful slowdowns that can point to stalls, retries, or busy dependencies.

Why average latency is not enough

Average latency can hide groups of slow requests. A report may look acceptable on average while a meaningful share of users still waits too long. Read average latency together with p95, p99, errors, and timeouts.

Ways to improve p95

1. Find slow database queries and add the right indexes or limits.
2. Move expensive work out of the request path when it does not need to block the response.
3. Cache expensive reads when freshness rules allow it.
4. Check app, database, cache, and upstream service concurrency limits.
5. Compare reports before and after each change so improvements are visible.

How to read a load test report

Start with the question the test was meant to answer. A homepage launch check, a checkout API validation, and a hosting comparison can all produce similar metrics, but the decision behind those metrics is different.

Check the sample size

Total requests and duration tell you how much evidence the report contains. A short run is fine for a smoke check. A longer run gives more confidence when caches, queues, databases, and external services are involved.

Read success before speed

Fast failures are still failures. If the error rate is high, inspect status codes, timeout count, and network errors before focusing on latency. A healthy result needs both correct responses and acceptable response time.

Compare throughput with latency

Requests per second shows throughput. If RPS rises while p95 latency climbs sharply, the system may be queueing work rather than handling traffic comfortably. If throughput drops while errors rise, check rate limits, worker capacity, database connections, or upstream dependencies.

Investigate status codes and timeouts

• 401 or 403 can mean missing or invalid authorization.
• 404 can mean the wrong URL was tested.
• 429 usually means rate limiting or protective traffic controls.
• 500-level responses point to application or infrastructure failures.
• Timeouts mean requests exceeded the wait limit and often feel broken to users.

Decide what happens next

1. If errors are high, fix correctness before optimizing speed.
2. If p95 or p99 is high, inspect slow queries, external calls, queueing, and cold starts.
3. If throughput is too low, check server limits, connection pools, workers, and rate limits.
4. If results look good, rerun the same scenario later to confirm the result is repeatable.

Website load testing checklist before launch

A launch test should be safe, specific, and easy to interpret. Use this checklist before sending traffic to a website or public page.

Before the test

• Confirm you own the site or have written permission to test it.
• Choose important pages, not only the homepage.
• Estimate launch traffic and convert it into request volume and concurrency.
• Prepare app logs, CPU, memory, database, cache, queue, and error monitoring.
• Protect production data by avoiding destructive or repeated write actions.

During the test

• Start with a low-traffic smoke test to catch wrong URLs or blocked requests.
• Watch error rate, timeout count, p95 latency, and status codes.
• Stop if failures climb unexpectedly or external services show warning signs.
• Increase traffic gradually only after the first run behaves as expected.

After the test

• Save JSON or CSV reports so future runs have a baseline.
• Compare p95 latency, p99 latency, error rate, and throughput after fixes.
• Create a rollback plan for slow launches, high errors, or capacity problems.
• Retest the same scenario after each important change.

API performance testing guide

API performance testing helps teams find slow endpoints, reliability gaps, and traffic limits before users do. It can include quick latency checks, short load tests, longer endurance runs, and focused tests around one suspected bottleneck.

Set a clear goal

Write the target before running the test. For example: can the search endpoint keep p95 latency under 500ms at expected launch traffic? Can the checkout API avoid timeouts when many users submit at once? Can a new index reduce p99 latency without increasing errors?

Choose realistic scenarios

• Use endpoints that match real user behavior.
• Include required headers, request bodies, and authentication patterns when safe.
• Separate read-heavy, write-heavy, and mixed workflows.
• Keep test data controlled so repeated requests do not damage records.

Watch for common bottlenecks

• Slow database queries, missing indexes, and large result sets.
• External API calls inside the request path.
• Connection pool limits between the app, cache, and database.
• Insufficient workers, threads, or serverless concurrency.
• Large JSON payloads, expensive serialization, or unnecessary response fields.
• Rate limits, WAF rules, or authentication services that become the limiting step.

A practical workflow

1. Run one small baseline test and save the report.
2. Identify the weakest metric: errors, timeouts, p95, p99, or throughput.
3. Use logs and infrastructure metrics to find the likely bottleneck.
4. Change one thing at a time.
5. Rerun the same scenario and compare results fairly.
6. Document the final safe operating range and known limits.

Repeatable validation workflow

Repeatability is what turns a one-off load test into useful evidence. Keep the scenario stable so the report shows the impact of the change, not the impact of different test settings.

1. Pick one important URL or API route.
2. Save the method, headers, body, request rate, concurrency, duration, and timeout.
3. Run the test before a deploy, launch, or infrastructure change.
4. Run it again after the change with the same settings.
5. Compare p95, p99, error rate, timeout count, status codes, and throughput.

For a full walkthrough, read before and after load testing.

Regression debugging checklist

When a report looks worse after a change, debug in an order that protects correctness first and speed second.

• Check failed requests, status-code changes, and timeouts before latency tuning.
• Compare p95 and p99 to see whether slower user experiences became more common.
• Look for new 429 or 500-level responses after the deploy.
• Connect the report to logs, traces, database metrics, cache metrics, and upstream API status.
• Change one thing at a time and rerun the same test so the fix can be measured fairly.

Use the full performance regression debugging guide when a deploy changes p95, p99, errors, or timeout behavior.

Competitor positioning tracker

Review niche competitors once per month to sharpen InstantLoad positioning. Track where specialized tools are narrower and where InstantLoad is simpler: no signup, browser-based workflow, website and API support, safe small tests, and downloadable JSON/CSV reports.

• Product name
• Target user
• Main use case
• Setup required
• Pricing
• Report quality
• Website/API support
• CLI/browser/API requirement

Use the comparison pages for public messaging: open-source comparison and CLI comparison.

Community outreach workflow

When someone asks for a free online load testing tool, reply with a helpful workflow first. Explain safe settings, the metrics to review, and mention InstantLoad only as one practical option if the platform allows links.

Reusable reply patterns live on the community reply templates page.