Troubleshooting load tests

Find the message or symptom you see, then read why it happens and what to do. Each entry links to the page with the full detail. Messages are quoted as the app shows them.

The test does not start

"Failed to start test"

What you see: a dialog titled Failed to start test with "Please try again. If you still encounter an error please contact us."

Why: LoadFocus could not launch the run, and the reason was not one of the plan limits below.

What to do: start the test again. A run that LoadFocus failed to start does not count against your plan's runs (see the last section of this page). If it keeps failing, contact support with the test name.

"Run limit reached"

What you see: the limits dialog says Run limit reached, with a line such as "Your plan includes 30 test runs in any 24 hours. Your team has used 30." and "The next run is available on" a date. Over the API, the refusal carries a reason such as number-of-daily-tests-exceeded, number-of-weekly-tests-exceeded, number-of-monthly-tests-exceeded or number-of-yearly-tests-exceeded, with the current and maximum counts.

Why: your team used all the runs its plan allows in that period. The weekly cap only applies to runs started through the API and to scheduled runs, on Load Free, during a trial and on Load Starter.

What to do: wait until the date shown, or move to a plan with more runs. Scheduled runs that hit a cap are skipped and say so in the schedule panel. See Plans and limits and Scheduled Load Tests.

"Your plan has reached the number of tests it can run at the same time."

Why: another test of your team is still running and your plan allows only that many at once.

What to do: wait for the running test to finish, or stop it. See Plans and limits.

Trial refusals: "You have used your trial runs", "This test needs more virtual users", "This website needs a paid plan"

Why: during the 7-day trial of a paid plan, tests run at reduced limits: 50 virtual users, tests of up to 5 minutes and 3 runs in any 24 hours across cloud, JMeter and k6 tests. A cloud test from a trial also cannot target a website that was already load tested from another trial or Free account.

What to do: the dialog offers to start your plan now, which lifts the trial limits straight away, or to add a card for 3 more runs today. See Limits during the 7-day trial.

"Free tests used up for this website"

Why: all Free accounts together get 3 tests a day and 10 a year for the same website, and that shared allowance is used up. It only applies once another account has tested that website in the same period.

What to do: the dialog says when you can test the website for free again. Your other websites are not affected, and paid plans have no shared allowance. See Limits on the Free plan.

"The test cannot run because the URL fields contain private IP addresses."

Why: a request URL points to localhost, a private address such as 192.168.x.x or 10.x.x.x, or a host name that resolves to one. Load generators run in the cloud and cannot reach your internal network.

What to do: test a public URL, or expose the local server with a tunnel. See What is a Valid URL for a Load Test and How to Load Test a Locally Hosted Website or API.

The test starts but fails

A k6 test ends as FAILED with no results

What you see: the k6 tests list shows FAILED and the results page opens a Test run failed dialog.

Why: the script failed before it sent any load: a syntax error, an import that cannot be loaded (such as a k6/x/... extension), or a setup() that throws or times out. A teardown() that throws after the test has run does not fail the run.

What to do: run the script locally with k6 run to find the error, fix it and upload it again. The k6 log file is on the Logs tab. See Analyzing k6 Load Test Results.

A JMeter test fails or sends fewer requests than expected

What you see: a Test run failed dialog with "Please try again. There were errors reported during the test run." and an excerpt of the JMeter log, or a run that finishes with far fewer samples than planned.

Why: JMeter reported errors while running your script, for example a missing plugin, a misconfigured thread group or a CSV file the script reads but that was not uploaded.

What to do: open the Logs tab, read the JMeter log file and search it for ERROR and WARN. See JMeter Log File Analysis and Logs & JTL File Analysis.

The results look wrong

The start-up screen says a test request was turned away

What you see: while a cloud test starts, a warning such as "Cloudflare turned away a test request to example.com from AWS us-east-1. Your load test may be blocked the same way."

Why: when a cloud run starts, LoadFocus sends one request to the root of the site from the run's region. A CDN or hosting edge in front of the site refused it. This is one request without your test's credentials, so it is a hint, not a verdict, and the run carries on.

What to do: watch the error rate of the run. If the results then show the filtering notice below, allow the test traffic in that platform's firewall or bot protection settings.

"... is probably filtering the test traffic."

What you see: on the results overview of a finished cloud test, a notice such as "Vercel is probably filtering the test traffic." or "This site appears to be rate limiting or blocking the test traffic."

Why: at least 20% of the requests ended with 403, 429, 430 (503 on Cloudflare) or a dropped or failed connection, which is what bot protection, DDoS protection and rate limits produce. The numbers describe that protection, not your site.

What to do: allow the test traffic using the IP ranges to allow, or test a staging deployment with the protection relaxed. See Errors by Type and Error Rate.

"Load generator near capacity - treat response times as a lower bound"

Why: at least one load generator reached 80% CPU or more during the run, so response times include time the generator spent waiting for its own CPU.

What to do: spread the users over more load generators or locations, remove expensive per-request work from the script, and run the test again. See Load Generator Saturation.

Connection errors: ConnectException, HttpHostConnectException, timeouts

What you see: rows in the Errors tab such as HttpHostConnectException, SocketTimeoutException or "The host name could not be resolved (DNS)." in the response code explanations.

Why: the load generators could not open a connection or got no answer: the host is down, the name does not resolve from the internet, or a firewall drops traffic from the generators.

What to do: check that the URL works from outside your network, and add the LoadFocus IP ranges to your firewall or WAF. If the errors only start at a certain number of users, it is a capacity limit: compare them with the virtual users line. See Errors by Type and Error Rate.

HTTPS errors: SSLException, SSLHandshakeException

What you see: SSLException or SSLHandshakeException in the Errors tab, or "The secure connection (TLS) could not be established."

Why: the TLS handshake failed. Common causes are an expired, self-signed or privately issued certificate, a protocol mismatch, or a server dropping handshakes under load.

What to do: check the certificate chain of the host, for example with the free SSL Checker. If the errors grow with the number of users, the server is struggling with handshakes. See Differences between HTTP and HTTPS.

An old run is marked Expired and its charts are empty

Why: raw results older than 1 year are deleted. The run stays in your list, but its charts have no data left to draw. Runs set as a baseline keep their raw results.

What to do: nothing to fix. See How long LoadFocus keeps your data.

Runs that do not count

• A run that LoadFocus failed to start does not count against your plan's run caps.
• A cloud test run that ended without sending a single request does not count either, up to two such runs a day.
• A run you stop yourself always counts, even before it sends load.

See Scheduled Load Tests for how skipped scheduled runs are reported.