> For the complete documentation index, see [llms.txt](https://docs.testvibe.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.testvibe.com/run-tests/schedule-runs.md).

# Schedule Runs

Scheduled runs let TestVibe execute selected tests on a recurring cadence without starting each run manually.

Use schedules for smoke checks, overnight regression coverage, staging environment monitoring, or any test set that should run at a predictable time. Schedules are managed as [Automations](/run-tests/automations.md) — the same surface can also trigger runs when another run finishes.

## Create a scheduled run

1. Open **Automations** from the navigation rail.
2. Select **+** (New automation) and enter a name.
3. For **Trigger mode**, choose **Time (cron)** and pick a schedule preset and timezone.
4. Set the **Run Settings** — site URL, the groups or tests to include, and one or more run configurations.
5. Leave **Enabled** on if the schedule should start running.
6. **Save** the automation.

TestVibe saves the automation to your project and starts a cloud test session automatically at each scheduled time.

## Frequency options

Pick a schedule preset, then choose a timezone:

| Frequency          | Use it for                                           |
| ------------------ | ---------------------------------------------------- |
| Every 15 minutes   | Fast feedback for highly active test environments.   |
| Hourly             | Frequent monitoring without running constantly.      |
| Daily at 02:00     | An overnight health check before the workday starts. |
| Daily at 09:00     | A morning health check for the team.                 |
| Weekly (Mon 06:00) | Weekly regression checks at the start of the week.   |

## Choose what the schedule runs

Schedules can target all groups or a selected subset. If no group is selected, TestVibe treats the schedule as an all-groups run.

Choose the smallest useful scope:

| Scope          | Best for                                                    |
| -------------- | ----------------------------------------------------------- |
| One group      | Monitoring a critical workflow such as sign-in or checkout. |
| Several groups | Daily confidence for the main product paths.                |
| Full suite     | Broad regression coverage on a slower cadence.              |

## Site URL source

A schedule can use:

| Source           | When to use it                                                 |
| ---------------- | -------------------------------------------------------------- |
| Explicit URL     | The schedule should always run against a specific environment. |
| Project site URL | The project already defines the correct app URL.               |

Use explicit URLs for staging, QA, preview, or dedicated test environments.

## Run now

Use **Run now** to start the schedule immediately without waiting for the next planned time. This is useful after creating or editing a schedule because it confirms the selected tests, URL, and configuration work together.

## Active-run behavior

Scheduled runs are designed to avoid overlapping work. If a previous scheduled run is still active, the next scheduled attempt may be skipped instead of starting another copy of the same run.

For execution environment options, including tunnel devices for private apps, see [Choose a runner](/runners/choose-a-runner.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.testvibe.com/run-tests/schedule-runs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.