Webinar - Join us on 26th Oct. to hear all about Selenium 4 and its exciting new features from David Burns, Core Contributor to Selenium. Register here


This document guides you with the steps to resolve the BROWSERSTACK_IDLE_TIMEOUT error.

This error occurs when a session is idle for more than the set timeout, which is generally 90 seconds. This happens as BrowserStack by default waits for the timeout duration for additional steps or commands to run, if BrowserStack does not receive any command during that time, the session is stopped, changing the session status to TIMEOUT on the Automate dashboard.

Following are some mechanisms to avoid this error:

Inform BrowserStack that a test is completed

BrowserStack does not know when you are done with all the steps in your Selenium test. The driver.quit Selenium command, helps us identify that all the steps of the Automate test are finished and the test is completed. You should call the driver.quit command after all the steps in your test script.

Refer to the below code snippets on how to call the driver.quit command in your test script:

Note: Sometimes it might be the case that you have driver.quit in your script but you are still facing IDLE_TIMEOUT. In most such cases, your test script has run into an unhandled exception and in that flow, the driver.quit is not encountered by the script and hence the timeout. Read more about handling exceptions.

Increase timeout duration

BrowserStack triggers the BROWSERSTACK_IDLE_TIMEOUT error when a session is left idle for more than 90 seconds. The browserstack.idleTimeout capability helps you to change the timeout value in case the web page takes longer than 90 seconds to open. You can set a timeout value from 0 to 300 seconds. The default value is 90 seconds.

Example code snippets for setting this capability is shown below:

DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("browserstack.idleTimeout", "300");
var capabilities = {
 "browserstack.idleTimeout" : "300"
// For Chrome browser
OpenQA.Selenium.Chrome.ChromeOptions chromeCapability = new OpenQA.Selenium.Chrome.ChromeOptions();
capability.AddAdditionalCapability("browserstack.idleTimeout", "300", true);

// For Edge browser
OpenQA.Selenium.Edge.EdgeOptions edgecapability = new OpenQA.Selenium.Edge.EdgeOptions();
capability.AddAdditionalCapability("browserstack.idleTimeout", "300");

// For IE browser
OpenQA.Selenium.IE.InternetExplorerOptions ieCapability = new OpenQA.Selenium.IE.InternetExplorerOptions();
capability.AddAdditionalCapability("browserstack.idleTimeout", "300", true);

// For Firefox browser
OpenQA.Selenium.Firefox.FirefoxOptions firefoxCapability = new OpenQA.Selenium.Firefox.FirefoxOptions();
capability.AddAdditionalCapability("browserstack.idleTimeout", "300", true);

// For Safari browser
OpenQA.Selenium.Safari.SafariOptions safariCapability = new OpenQA.Selenium.Safari.SafariOptions();
safariCapability.AddAdditionalCapability("browserstack.idleTimeout", "300");
$caps = array(
 "browserstack.idleTimeout" => "300"
capabilities = {
 "browserstack.idleTimeout": "300"
caps = Selenium::WebDriver::Remote::Capabilities.new
caps["browserstack.idleTimeout"] = "300"
my $capabilities = {
  "browserstack.idleTimeout" => "300"

Handle exceptions

Your test script can run into exceptions, resulting in the driver.quit command not getting fired. To handle such exceptions, you should use a try…catch block. A general approach to use try…catch in your test script:

  • Use a try…catch block.
  • Log the exception.
  • Handle the exception. If you are trying to find an element on a webpage, you can use a different XPath.
  • Continue running the remaining steps in your test script.
  • Trigger the driver.quit command at end of your test script or in the finally block of your try..catch block.

You can also implement waits in your script (explained in the next section) which will ensure that you do not run into exceptions unnecessarily.

Specifying waits in your test script

You might encounter scenarios in your Selenium scripts wherein you experience flaky behavior at times due to element not present or something similar. In most such scenarios, the usual culprit is the fact that due to the Page Load Strategy, the page is said to have loaded but various elements in the page might not still have loaded (those that are dependent on Javascript typically).

In such scenarios, you should implement waits in your test script so that you don’t end up in an exception state leading to timeouts eventually. The different waits that you can implement in your script are given below along with links for more details:

You can also configure a timeout in your test frameworks. For example, you may have configured a timeout of 30 seconds in your test framework. A request to open a web page may take longer than 30 seconds, in such a case the test would get timed out. You can refer to the below links for configuring timeout in your framework:

The above steps should help you resolve the BROWSERSTACK_IDLE_TIMEOUT error. If you need additional help, please contact our Support team.

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

Is this page helping you?


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!

Talk to an Expert
Talk to an Expert