Run Timeouts
Understand tests timeouts and how to avoid them
Last updated
Understand tests timeouts and how to avoid them
Last updated
New! We implemented auto-cancellation for GitHub Actions - stopping a workflow on GitHub will automatically cancel the associated run on Currents. See
If any of your spec files take too long to report the results back to Currents dashboard, the whole run is marked as timed out. Why is that?
Unfortunately, sometimes containers crash or become unresponsive due to various reasons, for example:
hardware failure
software bugs
preemptive termination (by user or OS)
Agents do not send their status to Dashboard when they are shut down or terminated.
Therefore, the dashboard service cannot determine whether the lack of response is due to a crash, termination or long-running test.
If no response is received from a container within a certain period of time, the whole run is marked as timed out.
The default timeout value is 30 minutes.
You can change the default timeout for each individual project in Project Settings. The minimum value is 3 minutes, the maximum value is 12 hours.
The default timeout value is 30 minutes.
Try changing the default timeout settings for your projects, that's usually sufficient. If you are still experiencing timeouts there are a few additional options.
Try rearranging your tests so that every spec file has a lower number of tests so that the overall spec runtime is less than the timeout.
page.waitForEvent and cy.wait Having a test that has many page.waitForEvent or cy.wait waiting for a considerable time can accumulate and increase the overall runtime of your tests. Try reducing the number of calls to page.waitForEvent or cy.wait (which is, in general, a good practice) or reduce the values of your wait periods.
Try using more powerful CI machines that can run your tests faster; tweak cypress video settings to tune the load of generating and compressing video recordings of your tests.
Examine your CI jobs log file and eliminate any crashes or instability that cause the containers to become non-responsive.
Open the Run Details view for a "timed out" run. Make sure that Run Summary tab is selected.
Explore the list of cypress agents and identify agents that are still in a "Running" state (marked in orange).
The spec file name that was will be marked as "Idle", hover the mouse cursor to see the details.
Open the Run Details view for a "timed out" run. Make sure that Run Summary tab is selected.
Explore the list of cypress agents and identify agents that are still in a "Running" state (marked in orange).
The spec file name that was will be marked as "Idle", hover the mouse cursor to see the details.
Open the Run Details view for a "timed out" run. Make sure that Spec Files tab is selected.
Filter the list of spec files, and make sure that only "Running" and "Idle" spec files are selected.
Spec files in "Running" state are likely to cause a time out
If no spec file was sent for execution but no results were received within 60 minutes, the spec file will be marked as "Idle"
Playwright runners do not notify the dashboard when they are stopped or halted, that's why the dashboard can't detect their termination. If no results are received for more than 30 minutes (or another timeout), the run will be marked as timed out. You can change the timeout value in project settings.
If your CI provider has such kind of a hook, please contact our support to assist with enabling auto-cancellation.
You can cancel runs from the dashboard. See Canceling Runs section.
The most common reason is prematurely terminating playwright/ currents process before letting it report all the results back to the dashboard.
If you're using a script / wrapper to run your cypress tests, please make sure that playwright / currents process finishes its execution completely.
Please use in-app support channel for assistance. Please make sure that all the spec files have successfully finished their execution on CI and reported the results back to the dashboard.
Certain CI providers provide a hook/lifecycle event that can be used to cancel Currents run automatically when a CI job is cancelled. See an example .
