# Run the Full Suite

URL: https://docs.testvibe.com/run-tests/run-full-suite

Run the full suite when you want broad confidence across the generated tests in a project. Full-suite runs are best after individual tests and key groups are already stable.

Because this option may run many browser sessions, it can take longer and may surface shared setup issues such as unavailable test data, expired credentials, or plan capacity limits.

## Before you start

Check the basics before launching a full suite:

| Check | Why it matters | A recent single test passed | Confirms the target site, cloud test session, and configuration are working. | Key groups are stable | Prevents one known setup issue from producing many noisy failures. | Credit balance is available | Full suites use more session time than focused runs. | Test data is ready | Shared accounts, seed data, and environment state affect many tests. | Secrets are current | Expired credentials can fail the whole run. 

## Start a full-suite run

1. Open **Runs** .
2. Select **New Run** .
3. Select all runnable tests in the test list.
4. Under **Environment** , pick the environment you want to validate (or a Custom URL).
5. Choose one or more **Run Configurations** .
6. Optionally set **Execution** — **Sequential** or a lower **Custom** cap reduces load on the target site during a large full-suite run, at the cost of a longer run; leave it on **Auto** otherwise.
7. Start the run.
If your suite is organized into groups, you can select all groups or select the top-level suite entry when available. Review the selected tests before starting so the run matches the scope you intend.

## When to use a full suite

Full-suite runs are helpful for:

| Situation | Why it helps | Release readiness | Confirms the main generated coverage passes before shipping. | Major UI changes | Catches regressions across multiple feature areas. | Nightly validation | Gives the team a regular signal on the state of the app. | Environment checks | Confirms staging or test deployments are usable end to end. 

For recurring coverage, see [Schedule runs](/run-tests/schedule-runs) .

## Review failures

Start with the overall run status and then inspect failed rows. A full suite can produce related failures from a single root cause, so look for patterns before editing many tests.

Common examples:

| Pattern | Likely next check | Many tests fail at sign-in | Check credentials, secrets, and login flow changes. | Failures start after a setup step | Review prerequisite steps and test data. | Only one group fails | Investigate that feature area first. | Only one browser or viewport fails | Review the selected run configuration. 

For evidence review, see [Review Results](/results) .