This document lists down the various timeouts that can occur in BrowserStack Automate sessions and their possible resolutions.
The following timeouts may appear in the STOP_SESSION logs of your sessions:
The default time interval that BrowserStack waits for a command is set to 90 seconds. If no new command reaches the BrowserStack hub after the previous command was served, the session ends with
BROWSERSTACK_IDLE_TIMEOUT. You can increase the timeout using the capability
It may also be the case, that all commands in your script has run but
driver.quit was not received at the end of the session. In such cases also, the session will end with
BROWSERSTACK_IDLE_TIMEOUT because BrowserStack does not know whether your test has ended.
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. We recommend 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.
While in most cases, it is seen that this is a one-off issue but, if you have been facing this issue repeatedly, then we suggest you reach out to BrowserStack Support with the details of the problem, and we would be happy to help you out.
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.
Contact our Support team for immediate help while we work on improving our docs.