--- title: Test Errors and Fixes | TestingBot description: 'Reference for the most common TestingBot test errors: minutes depleted, max duration, idle timeout, session cancelled, capability and authentication. What each means and how to fix it.' source_url: html: https://testingbot.com/support/other/errors md: https://testingbot.com/support/other/errors/index.md --- # TestingBot Test Errors and How to Fix Them Reference for the most common errors TestingBot returns when an automated or live test ends unexpectedly. Each section explains what triggered the error, the most common causes, and how to fix it. Errors appear on the test detail page in the dashboard and in the REST API response. ## Minutes depleted ### What it means The test failed because your account does not have enough test minutes left. New tests cannot be started on TestingBot until minutes are restored. ### How to resolve See [our pricing plans](https://testingbot.com/pricing) and upgrade your subscription to add minutes immediately, or wait for your monthly plan to reset. Free-tier accounts receive a fresh allowance each month. Enterprise plans can request additional minute pools mid-cycle. ## Test exceeded max duration ### What it means The test was terminated because it exceeded the maximum duration allowed. The default cap is 1800 seconds (30 minutes). ### Common causes - The test is genuinely long. Consider splitting it into multiple smaller, atomic tests. - Tests on the cloud can be slower than local runs because of network round-trips and remote VM startup. - The test is stuck in an endless loop, repeatedly sending commands. ### How to resolve - Break the test into smaller pieces. - Use the [maxDuration capability](https://testingbot.com/support/web-automate/selenium/test-options#maxduration) to raise the cap if you legitimately need a longer session. - Check for endless loops and add explicit timeouts to waits. ## Test idle timeout ### What it means TestingBot did not receive a new command from your Selenium or Appium script for more than 90 seconds (the default idle timeout). The session is terminated to prevent it from running forever and consuming all your minutes. ### Common causes - A missing `driver.quit()` at the end of the test. The runner finishes but the session keeps the browser alive. - The test script crashed, was interrupted, or lost internet connectivity. - A legitimately slow step that takes more than 90 seconds between commands. ### How to resolve - Ensure the test calls `driver.quit()` in a teardown or `finally` block so it always runs. - Run the test from a stable network. CI runners with unstable egress are a common cause. - Raise the timeout with the [idleTimeout capability](https://testingbot.com/support/web-automate/selenium/test-options#idletimeout) if you need more than 90 seconds between commands. ## New session cancelled before test start ### What it means Your test runner requested a new session, but it closed the connection before TestingBot could allocate a slot and return a session id. ### Common causes - Client connection timeout too short. iOS and Android simulators can take 60 to 120 seconds to boot. - Running more tests than your plan's concurrency limit. Queued tests still consume the runner's connection time. - Grid-side capacity issues during peak times. Check the [TestingBot status page](https://status.testingbot.com/). ### How to resolve - Raise the connection timeout in your test runner. For WebdriverIO use `connectionRetryTimeout: 210000` (3.5 minutes). For Selenium HttpClient set the equivalent socket timeout. - Confirm you are within the concurrent-session limit on your plan. - Subscribe to the [status page RSS feed](https://status.testingbot.com/) for incident notifications. ## Manual session ended due to inactivity ### What it means A Live (interactive) browser or device session was terminated because there was no mouse or keyboard input for an extended period. Live sessions are billed by the minute, so idle sessions are ended automatically to prevent runaway charges. ### How to resolve Start a new Live session when you are ready to continue. If you need a long-running pinned session for QA workflows, consider switching to an automated test with a deliberate `maxDuration` setting. ## Capability not found or browser unavailable ### What it means You will see a `CapabilityNotPresentOnTheGridException` (or a similar "browser not found" message) when the browser, version and platform combination you requested is not currently offered on the TestingBot grid. ### How to resolve - Check the live [supported browser list](https://testingbot.com/support/web-automate/browsers) for available combinations. - Use the version aliases `latest`, `latest-1`, `latest-2` when you do not need to pin to an exact version. TestingBot resolves them to the current top release. - Double-check the spelling and case of `platformName` values. Selenium 4 W3C uses `WINDOWS`, `macOS`, `LINUX`, etc. ## Authentication errors (401) ### What it means Your API key and secret were missing, malformed, or did not match the credentials on file. The grid rejects the session before any browser is allocated. ### How to resolve - Verify your key and secret in [your account settings](https://testingbot.com/members/user/edit). - Pass credentials inside `tb:options` (W3C or Selenium 4), not as top-level capabilities. - If you have rotated keys, update every CI secret store that references the old pair. ## More help Status incidents are posted at the [TestingBot status page](https://status.testingbot.com/) (RSS feed available). For anything not covered above, [contact our support team](https://testingbot.com/contact/new) with your session ID. The dashboard URL of the failed test is the fastest way for us to investigate. Was this page helpful? Yes No ## Looking for More Help? Have questions or need more information? You can reach us via the following channels: - [Email us](https://testingbot.com/contact/new) - [Join our Slack Channel](https://join.slack.com/t/testingb0t/shared_invite/zt-3bcw9xch-jk19~6XPs_xBrsAgAedkCw)