Online Load Testing Tools: How They Work and How to Choose One

An online load testing tool sends traffic to your website or API from cloud workers it runs for you. You enter a URL, choose how many virtual users or requests per second to send and for how long, and watch latency percentiles and errors in a browser tab. You do not install anything or manage load generators. A good one makes you prove you own the domain first, publishes its source IPs, and stops the test automatically when thresholds break.

What an online load tester actually does

Under the hood it is the same thing a CLI tool like k6, wrk or Vegeta does: open many connections and send HTTP requests at a controlled rate. The difference is where that runs and what is built around it:

• Generators are hosted. The traffic comes from the vendor's machines, not your laptop. Your laptop's uplink, CPU and open-file limit stop being the bottleneck. A laptop that hits "too many open files" at a few thousand sockets is measuring itself, not your server.
• Results are stored and shareable. Each run has a URL, so you can compare it with last week's run and send it to a colleague.
• Guardrails are enforced by the service. That means domain verification, rate caps per plan, thresholds and auto-stop.

Online vs local CLI vs self-hosted cluster

A local CLI is the better choice when the target is on localhost or a private network, or when you need a quick number while coding. See the best CLI HTTP load testing tools. For the full build-versus-buy decision, see build vs buy.

How to choose an online load testing tool

These are the online-specific checks. For general tool criteria, see what to look for in an HTTP load testing tool.

1. Does it make you verify the domain? If a service will load test any URL you paste, it will also let someone else test yours. Verification by DNS TXT record or a well-known file is the minimum.
2. Are source IPs published? Without them, your WAF, CDN bot protection or rate limiter will block the test, and you will end up benchmarking a 403 page. See load testing behind Cloudflare.
3. Can it hold an exact RPS? VU-only tools slow down when your server slows down, which hides the problem. You want an arrival-rate (open-model) mode. See VUs vs RPS.
4. Does it show p95 and p99, live? Averages hide the tail. See p95 vs p99 latency.
5. Thresholds and auto-stop. A test that keeps hammering a failing production service for 15 more minutes is an incident, not a test.
6. What happens at the plan limit? Is it a hard cap, an overage bill or a silent throttle? Read the pricing page for the word "overage."
7. API access for CI. Clicking a button before each release does not last. You need tokens and an API or schedules.
8. Max duration and VUs per test. Make sure your realistic peak fits. The concurrent users calculator turns analytics into a target.

Your first online load test in 5 minutes

These steps use LoadTester as the example. Other hosted tools follow a similar flow.

Minute 1: verify the domain

Add a DNS TXT record, or serve a file:

; DNS
_loadtester-verify.example.com.  300  IN  TXT  "<token from the app>"

# or a file served by your site
https://example.com/.well-known/loadtester-verify.txt

The file route is faster if DNS changes need a ticket. A TXT record survives redeploys.

Minute 2: allowlist the workers

Fetch the current worker IPs from https://app.loadtester.org/api/ips and add them to the WAF or rate-limit bypass list. Skip this and you may see 429s or challenge pages at about the point where the test gets interesting.

Minute 3: configure the test

• Target: one representative endpoint, not the homepage served from a CDN cache. An uncached product page or GET /api/search?q=... tells you more.
• Mode: exact RPS. Start at your current peak RPS from analytics, then a second run at 2 times that.
• Duration: long enough to get past warm-up. A few minutes is enough for a first look; see how long a load test should run.

Minute 4: set thresholds

Two thresholds cover most first tests: p95 < 400 ms and error rate < 2%, both with auto-stop. Adjust 400 ms to whatever your users already experience.

Minute 5: run and read

Watch the curves together, not one at a time:

• RPS flat, p95 flat: healthy at this rate. Try a higher one.
• RPS flat, p95 climbing steadily: requests are queueing. You are near capacity. See why latency increases under load.
• Errors appear suddenly: a limit was hit, such as connection pool, worker count or file descriptors. The status code tells you which layer.
• Achieved RPS below target: in RPS mode, the server could not keep up or the plan's cap was reached.

How to read load test results covers this in more depth.

Mistakes that make a first online test meaningless

• Testing the CDN. A cached homepage served from an edge returns in 20 ms at any load, and tells you nothing about your origin. Test an uncached path, or confirm with the response headers (cf-cache-status: HIT, x-cache: Hit from cloudfront, age:) that requests reach the origin.
• Defeating every cache. The opposite mistake: adding a random query string to every request turns a realistic 90% cache-hit page into a 0% one. Match production's cache behavior.
• One test account for all VUs. Hundreds of VUs logged in as the same user often contend on the same database rows or session record. That creates lock waits real traffic never has. Use a pool of accounts. See load test data.
• Counting 200s as success. Some apps return an error page with status 200, or a login page after a session expires. Check response size or content as well as status.
• No warm-up. The first 30 to 60 seconds include JIT compilation, empty caches and connection pool growth. Judge the plateau, not the start.
• Reading the average. An average of 180 ms can hide a p99 of 3 seconds. Use the latency percentile calculator to see how far they diverge.
• Running at production peak without telling anyone. Your test adds to real traffic. Pick a quiet window, or a staging environment sized like production.

Only test what you own

Load testing someone else's site without written permission is, in effect, a denial-of-service attack. It can violate computer misuse laws and your hosting provider's terms. That is why domain verification exists. A few practical rules:

• Your domain, your infrastructure. If you are on shared hosting or a managed platform, read its acceptable-use or load testing policy first. Some providers ask for notice.
• Third-party dependencies are not yours. A checkout flow that calls a payment provider or a SaaS API will load test their service too. Use their sandbox, or stub the call during the test.
• Tell people. Tell on-call and whoever watches the WAF. An unannounced load test can look like an attack and get your test traffic, or your office IP, blocked.
• Production needs a stop condition. Thresholds with auto-stop, a planned window, and someone watching. See the production load testing checklist.

Which plan fits a first online test

• Free ($0, no card): 10 VUs, 50 RPS, 1 minute, live charts, PDF and CSV export. Enough to learn the workflow and smoke-test an endpoint, not to find capacity.
• Starter ($19/mo): 250 VUs, 500 RPS, 5 minutes, scheduled tests, API tokens for CI and email alerts. Covers most small-to-medium sites and APIs.
• Pro ($49/mo, 7-day free trial): 2,000 VUs, 2,000 RPS, 20 minutes, 2 concurrent tests, Slack alerts, regression notifications. Fits launch rehearsals and team use.

Yearly billing saves 20%. There are no overage charges. When you hit a limit, you see an upgrade link.

Before you click Run

1. Domain verified, worker IPs allowlisted.
2. On-call and WAF owners notified, with the test window agreed.
3. Third-party calls sandboxed or stubbed.
4. Target RPS based on real analytics, not a guess.
5. Thresholds set with auto-stop.
6. Server-side dashboards (CPU, DB connections, error logs) open in another tab, so you can explain what the load test shows.