Connect and get help from 7,000+ developers on our Discord community.
Ask the Community
Ask the Community
BrowserStack Load Testing - Troubleshooting
Resolve common BrowserStack Load Testing issues and configuration errors quickly.
Use this page to troubleshoot common BrowserStack Load Testing issues and configuration problems.
Common issues and resolutions
Refer to the following tables to diagnose and resolve common load test setup and runtime problems.
Selenium (Java/JUnit/TestNG)
Use the following table to diagnose common Selenium Java, JUnit, and TestNG configuration issues.
| Issue | Remediation |
|---|---|
| Default source directory not found | If you do not override testSourceDirectory, BrowserStack expects tests under src/test/java. Confirm this path exists in the ZIP and that it contains your Java test files. |
Vanilla Java project includes test framework dependencyError: pom.xml contains TestNG/JUit dependencies - this is a TestNG project, not Selenium - Vanilla Java
|
If you run plain Java tests without TestNG or JUnit, remove any unused test framework dependencies from pom.xml to avoid configuration conflicts.Remove the TestNG/JUnit dependencies. |
| Test files not detected (ZIP root mismatch) | BrowserStack executes tests from the root of the uploaded ZIP. Update your configuration so that all test paths are relative to the ZIP root and re-upload the archive. |
| No TestNG dependency | Your pom.xml is present, but it does not include the TestNG dependencies. Add the appropriate test framework dependency and upload the updated project.TestNG dependency list: ["testng", "org.testng"]
|
| No JUnit dependency | Your pom.xml is present, but it does not include the JUnit dependencies. Add the appropriate test framework dependency and upload the updated project.JUnit dependency list: ["junit","junit-jupiter-api","junit-jupiter-engine","org.junit","org.junit.jupiter"]
|
Source directory not found (custom testSourceDirectory) |
If you use a custom <testSourceDirectory> in your Maven pom.xml under the <build> section, verify that the path exists in the uploaded ZIP and contains your .java test files. Following is an example pom.xml snippet:build <testSourceDirectory>src/ui-tests/java</testSourceDirectory>buildThe critical requirement is that the path specified in <testSourceDirectory> exists and includes at least one .java file; otherwise, Maven does not pick up the tests. |
Playwright
Use the following table to diagnose common Playwright test discovery and configuration issues.
| Issue | Remediation |
|---|---|
Test files not detected (testDir not pointing to tests) |
Verify that the testDir path in your Playwright configuration points to the folder inside the ZIP that contains your test files. |
Test files not detected (testMatch pattern) |
Check that the testMatch pattern in your Playwright configuration matches your test file names and extensions so BrowserStack can discover them. |
| Test files not detected (ZIP root mismatch) | BrowserStack executes tests from the root of the uploaded ZIP. Update your configuration so that all test paths are relative to the ZIP root and re-upload the archive. |
| Test files excluded by configuration | Review any exclude patterns in your configuration and make sure at least one test file is not excluded so BrowserStack can find and run your tests. |
Nightwatch
Use the following table to diagnose common Nightwatch configuration issues.
| Issue | Remediation |
|---|---|
Test files not detected (src_folders not set) |
Set src_folders in your Nightwatch configuration to a directory that exists in the ZIP and contains your test files. |
| Test files excluded by configuration | Review any exclude patterns in your configuration and make sure at least one test file is not excluded so BrowserStack can find and run your tests. |
| Test files not detected (ZIP root mismatch) | BrowserStack executes tests from the root of the uploaded ZIP. Update your configuration so that all test paths are relative to the ZIP root and re-upload the archive. |
WebdriverIO
Use the following table to diagnose common WebdriverIO configuration issues.
| Issue | Remediation |
|---|---|
Test files not detected (specs not set) |
Set specs in your WebdriverIO configuration to a directory that exists in the ZIP and contains your test files. |
| Test files excluded by configuration | Review any exclude patterns in your configuration and make sure at least one test file is not excluded so BrowserStack can find and run your tests. |
| Test files not detected (ZIP root mismatch) | BrowserStack executes tests from the root of the uploaded ZIP. Update your configuration so that all test paths are relative to the ZIP root and re-upload the archive. |
Python
Use the following table to diagnose common Python test configuration issues.
| Issue | Remediation |
|---|---|
| Target file not found (Python) | Ensure that your ZIP includes the configured target test file and that it exists with a .py extension, as this file is the entry point for running your Python tests. |
| Test files not detected (ZIP root mismatch) | BrowserStack executes tests from the root of the uploaded ZIP. Update your configuration so that all test paths are relative to the ZIP root and re-upload the archive. |
API load testing
Use the following sections to diagnose setup and runtime failures in API load tests (k6, JMeter, Locust, and Gatling). Every issue listed is something you can fix in your test bundle or configuration. If your issue isn’t listed here, contact BrowserStack Support with your test run ID, framework, and any available logs.
k6
Use the following table to diagnose k6 script and configuration issues.
| Issue | Remediation |
|---|---|
| Script fails to start | Common causes are syntax errors in your .js file, bad import paths, invalid thresholds expressions, or a throw statement at the top of the script. Validate locally by running k6 run --vus 1 --duration 5s script.js. |
| Missing runtime environment variables | If your script reads __ENV.AUTH_TOKEN or similar values, declare every required variable in the test configuration before running. |
| Target host unreachable | Private networks, VPN-only environments, and firewalled targets are not reachable from BrowserStack runners. Use a public-facing endpoint. |
| TLS handshake failure | Use a certificate from a trusted CA. For internal non-production targets only, you can set insecureSkipTLSVerify: true in your options block. Do not use this in production environments. |
JMeter
JMeter issues are split by when they occur: before the test starts and during test execution.
Before the JMeter test starts
The following initialization errors occur before load generation begins.
| Issue | Remediation |
|---|---|
test.yml YAML syntax error |
Validate the file locally by running python3 -c "import yaml; yaml.safe_load(open('test.yml'))". Common causes are tabs instead of spaces, missing colons, and unbalanced quotes. |
During JMeter test execution
The following errors occur once load generation starts.
| Issue | Remediation |
|---|---|
Bad scenario reference in test.yml
|
The execution[].scenario value must match a name in the scenarios: block. Keep both in sync. |
Time-unit parse error in hold-for or ramp-up
|
Always include units when specifying durations, for example 30s, 5m, or 1h. Taurus rejects bare numbers. |
| JMX parse error | Open the JMX file in JMeter Desktop and confirm it loads and runs locally before uploading. |
| Missing JMeter plugin | Include the plugin JAR inside lib/ext/ in your ZIP, or remove the plugin dependency from the JMX. |
| Missing runtime environment variables |
${__P(propName)} and ${__env(VAR)} references must have the variable declared in the test configuration. |
| Target host unreachable | Private networks, VPN-only environments, and firewalled targets are not reachable from BrowserStack runners. Use a public-facing endpoint. |
| TLS handshake failure | Use a certificate from a trusted CA, or accept self-signed certificates in the HTTP request defaults in your JMX for internal targets. |
Locust
Locust issues are split by when they occur: before the test starts and during test execution.
Before the Locust test starts
The following initialization errors occur before load generation begins.
| Issue | Remediation |
|---|---|
| Configured locustfile not in bundle | Confirm the file exists at the configured path in the ZIP with matching filename casing. |
| Failed to install Python dependencies | Validate requirements.txt locally in a clean virtual environment. Pin your dependency versions, and avoid private indexes. BrowserStack runners can only reach public PyPI. |
During Locust test execution
The following errors occur once load generation starts.
| Issue | Remediation |
|---|---|
| Locustfile import error | Common causes are missing modules, syntax errors, and unresolved relative imports. Test locally by running locust -f your_file.py --headless -u 1 -r 1 -t 5s. |
No @task or no User class defined |
Make sure your file has at least one User subclass with at least one @task method. |
| Missing runtime environment variables | Declare every os.environ access in your test configuration before running. |
| Target host unreachable | Private networks, VPN-only environments, and firewalled targets are not reachable from BrowserStack runners. Use a public-facing endpoint. |
| TLS handshake failure | Use a certificate from a trusted CA. For internal non-production targets only, you can pass verify=False. Do not use this in production environments. |
Gatling
BrowserStack overrides your simulation’s injection profile at runtime. The values from your BrowserStack test configuration replace whatever you put in setUp(...).inject(...) in your simulation file. The rest of your simulation logic, including scenarios, checks, requests, and feeders, is preserved as written.
Use the following table to diagnose Gatling build and simulation issues.
| Issue | Remediation |
|---|---|
pom.xml, build.gradle, or build.sbt is malformed |
Validate locally with mvn validate, gradle build --dry-run, or sbt validate. |
| Simulation class not found | The configured simulation class name must match a class in src/test/scala. |
| Dependency resolution failure | Dependencies must be available on Maven Central. Private or internal repositories are not reachable from BrowserStack runners. Pin a known-good Scala version and a compatible Gatling version. |
| Scala compile error in simulation | Align your local Scala version with what your Gatling version expects. |
| Missing runtime environment variables | Declare every System.getenv or sys.env reference in the test configuration before running. |
| Target host unreachable | Private networks, VPN-only environments, and firewalled targets are not reachable from BrowserStack runners. Use a public-facing endpoint. |
| TLS handshake failure | Use a certificate from a trusted CA, or accept self-signed certificates in the HTTP protocol configuration in your simulation for internal targets. |
Generic errors
Use the following table to diagnose general errors that apply across all load test types.
| Issue | Remediation |
|---|---|
| Third-party connectors are added | If you use third-party connectors and tests fail to start or behave unexpectedly, contact BrowserStack Support with your test run ID and configuration details. |
| Test fails with Sync Failed | If the test fails with a Sync Failed error, contact BrowserStack Support and share the test run ID and logs so the team can investigate. |
| Tests are stuck in initialization | If tests remain in the initialization state for an extended period, contact BrowserStack Support with your configuration and test run ID for further analysis. |
| Tests ran but no data generated | If tests appear to run but no metrics are generated, contact BrowserStack Support so the team can review your configuration, logs, and network connectivity. |
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
Thank you for your valuable feedback!