Skip to main content
Transform your testing process with: Real Device Features, Company-wide Licences, & App Percy
No Result Found
Get your setup working faster. Join our Discord for optimisation tips from elite testers. Join our DiscordJoin our Discord

Stop XCUITest builds automatically with fail fast

Automatically stop an XCUITest build on App Automate after a specified number of tests fail, so you save device time and get results faster.

Continuing a test run after a known failure wastes limited device farm capacity. Fail-fast execution aborts the build as soon as a specified failure threshold is reached, returning results faster and freeing up hardware for other queued jobs.

Enable fail fast

To enable fail fast, set enabled to true and maxFailures to the number of failed tests that stops the build:

Copy icon Copy

Keep the following in mind:

  • maxFailures accepts an integer from 1 to 1000.
  • Setting enabled to true without maxFailures fails validation.

Fail fast is not supported when singleRunnerInvocation is set to true:

  • All test cases run together in a single instrumentation process, so there is no boundary between individual tests for BrowserStack to stop at.
  • If you set both parameters together, your build request fails validation and returns an error.
  • To use fail fast, keep singleRunnerInvocation set to false, which is the default.

For more information, see Single runner invocation.

How failures are counted

Fail fast counts a test as failed only after all its retries are exhausted.

XCUITest resolves test retries inline during the active test execution. Fail-fast evaluates failures immediately upon final invocation, eliminating any pending state or secondary retry queue.

You can combine fail fast with retrying flaky tests. Fail fast only counts a test as failed once its retries are exhausted.

What happens when a build stops

Reaching the fail-fast threshold triggers a coordinated shutdown across running tests, queued sessions, and the dashboard. The following sections describe each part of that process.

Build termination behavior

Reaching a fail-fast threshold halts suite execution gracefully at the next test boundary. Active test invocations complete their execution cycle—the system never terminates a running test mid-flight.

Queue and state handling

When a build halts, the runner cleans up active execution slots and updates pending job statuses across the pipeline:

  • Active invocations: Run to completion before the suite halts.

  • Unexecuted tests: Marked as skipped rather than failed to preserve accurate failure ratios.

  • Queued sessions: Canceled immediately, returning parallel device slots to your organization’s concurrency pool for pending builds.

Dashboard reporting

The execution dashboard flags the run as automatically terminated due to failure threshold limits. This distinguishes automated fail-fast cancellations from manual developer interventions in your build telemetry and audit logs.

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?

Yes
No

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
Download Copy Check Circle