> ## Documentation Index > Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Run tests on a schedule > Schedule recurring Qodex runs for smoke checks, regressions, and security coverage against a chosen environment. # Run tests on a schedule Schedules let Qodex run scenarios automatically. Use them for nightly regression, hourly smoke checks, security sweeps, or recurring validation against a staging or production environment. A schedule stores the run scope, environment, cron expression, timezone, and notification settings. When the schedule fires, Qodex creates a normal test run and records results in the same history as manual runs. ## What a schedule controls Each schedule defines: * **Run scope**: all active scenarios, scenarios by tag, or scenarios and groups you pick. * **Environment**: the target environment for base URLs, credentials, and variables. * **Cron expression**: when the run should fire. * **Timezone**: how the cron expression should be interpreted. * **Notifications**: who should be notified and when. Draft scenarios are skipped for broad scheduled runs so unfinished agent drafts do not break nightly checks. ## Create a schedule Open **Test > Test runs**, click **Schedules**, then click **New schedule**. Give it a **Name** and an optional **Description**, then choose **What to run**: | What to run | What it runs | | - | - | | All Active Scenarios | Every active scenario and scenario group in the project. | | Scenarios by tag | Active scenarios and groups whose tags match the tags you pick. | | Select manually | The exact scenarios and groups you pick under **Scenarios and groups**. | Scenario groups run as one unit. Sequential groups run members in order and can stop on first failure. Parallel groups run members independently at the same time. See [Test groups and folders](https://qodex.ai/docs/run-tests-test-groups-and-folders.md) for the full behavior. ## Choose the environment Pick the target from the **Environment** dropdown. It lists the project's own environments, and a new schedule starts on the project's default environment. If the project has no environments yet, the dropdown says **No environments configured**; add one on the **Environments** page first. If an environment a schedule uses is later deleted, editing the schedule shows that it no longer exists so you can pick another. When the environment is read-only or has destructive tests turned off, scenarios tagged `destructive` are skipped in each scheduled run. See [Sensitive endpoints](https://qodex.ai/docs/security-testing-sensitive-endpoints.md). ## Choose the cadence Pick a preset under **Schedule**: **Every 15 minutes**, **Every hour**, **Every 6 hours**, **Every night at 2am**, **Every Monday at 9am**, or **Custom**. With **Custom**, enter a standard five-field cron expression. ```cron theme={null} # every 15 minutes */15 * * * * # every weekday at 08:30 30 8 * * 1-5 # every Monday at midnight 0 0 * * 1 ``` Set the **Timezone** on the schedule so human-readable times stay correct. Click **Create** to save. ## Pause, resume, or run now Use **Pause** on the schedule card to stop recurring execution, and **Resume** to start it again. Pausing keeps the schedule definition intact, and the card shows **PAUSED**. If you want CI to fire a schedule on demand, click **Edit** and use the **CI/CD trigger** section: click **Generate URL**, then **Copy**. A POST to that URL runs the schedule even while it is paused, without advancing its cron clock. **Regenerate** replaces the URL and stops the old one working immediately. ## Read the schedule card Each card shows what it runs, its cadence, when it last ran, and when it runs next. Badges explain anything unusual: | Badge | Meaning | | - | - | | **PAUSED** | The schedule is paused. | | **RETRYING** | The run could not be started yet and the scheduler is retrying it. The reason is shown on the card. | | **SKIPPED** | The last tick found no runnable scenarios, for example nothing matched the filter or the matches were drafts. | | **ERROR** | The last slot could not start at all, even after retries. The reason is shown on the card. | | **N CONSECUTIVE FAILURES** | The schedule has failed several runs in a row. | Project admins are emailed when a scheduled slot cannot start, at most once a day per schedule. ## Delete a schedule Open **Schedules**, find the schedule, click **Delete**, and confirm **Delete**. This permanently removes the schedule and stops its future recurring runs. If you may use the same schedule again, use **Pause** instead. Pausing preserves the schedule definition without running it on its normal cadence. ## Notifications Under **Notifications**, set: * **Notify on**: **Every run (pass + fail)**, **Failures only**, or **Never**. * **Notify emails (comma-separated)**: leave empty to email the project admins. Each recipient gets their own copy. * **Webhook URL (optional)**: a Slack incoming webhook URL receives a formatted Slack message. Any other URL receives a JSON POST with the event, project, result, summary, failed scenarios, and a link to the run. Emails say what each failure was, using the same labels as the run page. A failed run is emailed when it has a new functional regression or vulnerability. Qodex holds the email when every failure is a test repair, an environment problem, or an issue that was already open, and waits while some failures are not judged yet. When a schedule keeps failing the same way run after run, Qodex sends one broken-schedule email a day instead of a copy of the report every time. Each scheduled run's page shows what was sent, for example **Email sent to 3 recipients**, **No email: no new regressions**, or **Webhook failed (404)**. ## Related > [card] [Run tests via webhook](https://qodex.ai/docs/run-tests-via-webhook.md) > > Trigger a schedule or run from an external system. > [card] [Run the full suite](https://qodex.ai/docs/run-tests-full-suite.md) > > Understand the scope used by nightly regressions. > [card] [Test groups and folders](https://qodex.ai/docs/run-tests-test-groups-and-folders.md) > > Learn how grouped scenarios run on schedules. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.