# Scheduling

{% hint style="info" %}
**Who is this for?** SDETs, QA managers, and engineering managers who want to run test plans automatically on a recurring schedule — nightly regression, hourly smoke tests, or pre-release verification.
{% endhint %}

ContextQA allows test plans to run automatically on a recurring schedule without manual intervention. Scheduled runs are configured at the test plan level using either a cron expression for precise timing control or a frequency preset for common patterns. Scheduled results can be broadcast to Slack channels or email recipients so failures surface immediately.

## Prerequisites

* You have a test plan created and configured with at least one test suite and an environment.
* You have confirmed the test plan executes successfully when run manually at least once.
* For notification setup: you have connected a Slack workspace or provided email addresses in workspace notification settings.

***

## Creating a Schedule

1. Navigate to **Test Development → Test Plans**.
2. Click on the test plan you want to schedule.
3. Inside the test plan, click the **Schedules** tab.
4. Click **+ Add Schedule**.
5. The schedule configuration dialog opens. Fill in the following fields:

### Schedule Configuration Fields

**Schedule Name** A descriptive label for this schedule. Use names that describe the timing and purpose, e.g., "Nightly Regression — Staging", "Hourly Smoke — Production", "Pre-Release Full Suite".

**Frequency Type** Select **Cron Expression** for full timing control, or **Preset** for common intervals.

**Preset options:**

* Every 15 minutes
* Every 30 minutes
* Hourly
* Every 6 hours
* Daily
* Weekly (select day of week)
* Monthly (select day of month)

**Cron Expression** (if Cron Expression is selected) Enter a standard 5-field cron expression. See the [Cron Expression Reference](#cron-expression-reference) section below.

**Timezone** Select the timezone in which the cron expression should be interpreted. Defaults to UTC. For business-hours schedules, select your team's local timezone so the expression matches your working hours rather than UTC offsets.

**Active / Inactive** Toggle the schedule on or off. Inactive schedules are preserved but do not run. Use this to temporarily pause a schedule without deleting it (e.g., during a planned maintenance window or holiday freeze).

6. Click **Save Schedule**.

The schedule appears in the Schedules tab with its next scheduled run time displayed.

***

## Cron Expression Reference

ContextQA uses standard 5-field POSIX cron syntax:

```
┌─────────────── minute (0–59)
│ ┌─────────────── hour (0–23)
│ │ ┌─────────────── day of month (1–31)
│ │ │ ┌─────────────── month (1–12)
│ │ │ │ ┌─────────────── day of week (0–6, Sunday=0)
│ │ │ │ │
* * * * *
```

### Common Cron Examples

| Expression        | Meaning                                        |
| ----------------- | ---------------------------------------------- |
| `0 9 * * 1-5`     | Every weekday (Mon–Fri) at 9:00 AM             |
| `0 */6 * * *`     | Every 6 hours (midnight, 6 AM, noon, 6 PM)     |
| `0 0 * * 0`       | Every Sunday at midnight                       |
| `30 8 1 * *`      | First day of each month at 8:30 AM             |
| `0 2 * * *`       | Every day at 2:00 AM                           |
| `*/15 * * * *`    | Every 15 minutes                               |
| `0 6,12,18 * * *` | At 6 AM, 12 PM, and 6 PM every day             |
| `0 8 * * 1`       | Every Monday at 8:00 AM                        |
| `0 23 * * 5`      | Every Friday at 11:00 PM                       |
| `0 0 1,15 * *`    | On the 1st and 15th of every month at midnight |

### Cron Tips

* **Use specific hours, not `* * * * *`** — a cron running every minute will exhaust your execution concurrency slots and produce overwhelming notification noise.
* **Offset your schedules** — if multiple test plans are scheduled for "midnight", stagger them by 15–30 minutes (00:00, 00:15, 00:30) to avoid queuing all of them simultaneously.
* **Remember UTC vs local time** — if you set timezone to UTC and your team is in EST (UTC-5), `0 9 * * 1-5` runs at 9 AM UTC = 4 AM EST. Set the timezone to your local timezone to avoid this confusion.

***

## Viewing Scheduled Runs

**Upcoming schedule list:** Navigate to **Test Plans → your plan → Schedules tab**. Each schedule row shows:

* Schedule name
* Cron expression or preset
* Timezone
* Last run time and status
* Next scheduled run time
* Active/Inactive toggle

**Execution history:** All scheduled runs appear in **Execution History** alongside manually triggered runs. Scheduled runs are labeled with a clock icon to distinguish them from manual triggers.

**Across all plans:** Navigate to **Test Plans → Schedules** (the workspace-level schedules view) to see all active schedules across all test plans, sorted by next run time. This provides a consolidated view for scheduling hygiene — identifying overlapping schedules, dormant schedules that should be deactivated, or gaps in coverage.

***

## Pausing and Resuming Schedules

**To pause a schedule:**

1. Navigate to the plan's Schedules tab.
2. Find the schedule and toggle **Active** to Off.

The schedule is preserved with all its settings. The next run time is no longer calculated or displayed while the schedule is inactive.

**To resume a schedule:** Toggle **Active** back to On. The next run time is recalculated from the current time based on the cron expression.

**To delete a schedule:** Click the three-dot menu (⋮) on the schedule row → **Delete**. Deleting a schedule removes it permanently. The execution history from past scheduled runs is not affected.

***

## Notifications for Scheduled Runs

Scheduled runs that execute overnight or on weekends need to surface failures to the right people without requiring anyone to manually check the portal.

### Slack Notifications

1. Navigate to **Test Plans → your plan → Settings**.
2. Under **Notifications**, enable **Slack**.
3. Select the Slack channel to notify.
4. Configure the notification trigger:
   * **On failure only** — only send a Slack message when the scheduled run has at least one failed test case. This is recommended for most teams to avoid notification fatigue from successful runs.
   * **Always** — send a Slack message for every scheduled run result (pass or fail).
5. Save the plan settings.

The Slack notification includes:

* Test plan name and execution ID
* Overall pass/fail status
* Pass/fail counts and percentages
* A direct link to the execution report in the portal

### Email Notifications

1. Navigate to **Test Plans → your plan → Settings**.
2. Under **Notifications**, enable **Email**.
3. Enter one or more email addresses (comma-separated).
4. Configure the notification trigger (On Failure or Always).
5. Save.

***

## Scheduled Run Best Practices

### Smoke Tests — Run Frequently

Schedule a lightweight smoke test plan to run every hour against your staging environment. Smoke tests should cover the 5–10 most critical user flows and complete in under 5 minutes. Hourly smoke tests catch deployment issues or environment outages within 60 minutes.

```
Smoke Plan — Staging
Cron: 0 * * * *  (every hour)
Timezone: UTC
Notification: Slack #alerts-qa — On failure only
```

### Full Regression — Run Nightly

Schedule the full regression test plan to run overnight before your team starts work. This ensures every morning begins with a clear picture of the application's health across all features.

```
Regression Plan — Staging
Cron: 0 1 * * *  (1:00 AM every night)
Timezone: America/New_York
Notification: Slack #qa-daily-report — Always
             Email: qa-team@company.com — On failure only
```

### Pre-Release Verification — Run Against Production

Schedule a production verification run to execute after each deployment window. This confirms the deployment did not break critical paths in the live environment.

```
Production Verification Plan
Cron: 0 10 * * 1-5  (10 AM weekdays — after deployment window)
Timezone: America/New_York
Notification: Slack #deployments — Always
             Email: engineering-lead@company.com — On failure only
```

### Freeze Periods

Before a planned maintenance window or during a code freeze:

1. Navigate to each active schedule.
2. Toggle **Active** to Off.
3. Document the pause in your team's change log.
4. Resume schedules after the maintenance window closes.

***

## Tips & Best Practices

* **Schedule against stable environments.** Avoid scheduling test plans against environments that have deployments running at the same time the tests execute. A test failure caused by a mid-deployment restart is a false negative that erodes confidence in the test suite.
* **Use different schedules for different environments.** Run smoke tests hourly on staging and daily on production. Run full regression on staging nightly and on production only before major releases.
* **Stagger schedules to avoid concurrency conflicts.** If you have 3 test plans all scheduled for midnight, offset them by 10–15 minutes each. Running `0 0 * * *`, `15 0 * * *`, `30 0 * * *` ensures they execute sequentially without competing for the same execution slots.
* **Review the weekly schedule list every sprint.** Schedules accumulate over time. Regularly review the workspace-level Schedules view to deactivate schedules for features that have been deprecated, test plans that have been superseded, or environments that no longer exist.
* **Test your notification setup before relying on it.** Trigger a deliberate failure (temporarily modify a test case to assert something false) on a scheduled run to confirm that Slack and email notifications are delivered as expected.

## Troubleshooting

**A scheduled run did not execute at its configured time** Check the schedule's timezone setting. If the cron expression is `0 9 * * *` but the timezone is UTC and your expectation was 9 AM EST, the run executed at 9 AM UTC (4 AM EST). Update the timezone to match your local time.

Also check whether the schedule was marked Inactive. The Active/Inactive state is shown in the Schedules tab.

**Scheduled runs are queuing instead of executing** Your workspace's concurrent execution limit was reached at the scheduled time. This happens when multiple schedules fire simultaneously or when a previous scheduled run is still in progress when the next one triggers. Stagger your schedules and review whether any executions are taking unusually long to complete.

**Slack notifications are not being received** Verify that the Slack integration is connected in workspace Settings → Integrations → Slack. If the connection was recently revoked (e.g., a Slack workspace admin removed the ContextQA app), the integration must be re-authorized. Check that the configured Slack channel still exists and that the ContextQA Slack app has permission to post to it.

**I need a schedule that runs at different times on different days** Use multiple schedule entries on the same test plan. You can add any number of schedules to a plan. Create one schedule for weekday timing and a separate schedule for weekend timing. Both will appear in the Schedules tab and can be managed independently.

## Related Pages

* [Running Tests](https://learning.contextqa.com/execution/running-tests)
* [Configuring Environments](https://learning.contextqa.com/execution/environments)
* [Managing Test Suites](https://learning.contextqa.com/web-testing/managing-test-suites)
* [Integrations](https://learning.contextqa.com/integrations/integrations)

{% hint style="info" %}
**10× faster with parallel execution across browsers and devices.** [**Book a Demo →**](https://contextqa.com/book-a-demo/) — See ContextQA run your full test suite in parallel CI/CD execution.
{% endhint %}