Specifically, 10 minutes, which is the duration it can go before travis itself will time out (if there is not output). This is needed because we set workerCount=3 to improve our runtime, however travis doesn't always seem to have that much compute available; so when travis is resource-starved and we're running on one real thread, two test runners sit idle (due to resource starvation) and get timed-out by the watchdog process during test running (as a timeout is started from the instant a test or batch is sent to the worker). This timeout should be long enough that such that timeouts no longer occur on travis. (Timeouts are mostly for bailing on infinite-loop scenarios when testing locally, after all - and in such situations on travis, even a 10 minute timeout would be sufficient to catch the issue) You can easily replicate such a timeout scenario locally by setting your local worker count more than twice what's reasonable for your system.

This should fix recent spurious build failures like this one.