Handling timeouts on Automate sessions

Learn about the different timeouts like Idle Timeout, SO Timeout and Session Limit Reached on BrowserStack Automate and their possible resolutions.

Timeouts in automated testing refer to the specified maximum duration a script waits for a condition to be met before throwing an error. In BrowserStack Automate, timeouts manage how long a test will wait for actions like page loading, script execution, or element interaction to complete.

This guide covers the following type of timeouts

• Idle timeout
• SO timeout
• Session limit reached

These timeouts may appear in the STOP_SESSION logs of your sessions:

Idle timeout

The default time interval that BrowserStack waits for a command is set to 90 seconds. If no new command reaches the BrowserStack hub 90 seconds after the previous command was served, the session ends with BROWSERSTACK_IDLE_TIMEOUT. You can increase the timeout using the capability idleTimeout. Example:

idleTimeout: 300

"browserstack.idleTimeout": 300

It may also be the case, that all commands in your script have run but driver.quit was not received at the end of the session. In such cases, the session ends with BROWSERSTACK_IDLE_TIMEOUT because BrowserStack cannot detect if the test has ended.

SO timeout

Socket timeouts or SO_TIMEOUT happen when the browser becomes unresponsive for a period of 240 seconds post which, the unresponsive browser is killed, changing the session status to ERROR on the Automate dashboard.

The browser could have become unresponsive for several reasons, including but not limited to unhandled pop-ups. BrowserStack recommends you to go through the session’s video where you have observed SO_TIMEOUT and see whether there is any unhandled pop-up in the active window.

In most cases, this is a one-time issue. However, if you encounter this problem repeatedly, please reach out to BrowserStack Support.

Session limit reached

BrowserStack Automate supports session durations up to 2 hours. If a session is running for more than 7200 seconds (2 hours), the session is stopped, changing the session status to TIMEOUT on the dashboard.

To avoid such a scenario, you can divide your test into multiple smaller tests which can then run on their individual sessions. This timeout might also be caused when your test framework misbehaves. In any such scenario, you can always choose to stop the session manually from the Automate dashboard.