> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/execution/scheduling.md). # 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 runs test plans automatically on a recurring schedule without manual intervention. You configure scheduled runs at the test plan level by choosing a start date and time and a repeat frequency. Scheduled results surface through email and Slack notifications so failures reach the right people 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 have recipient email addresses ready. *** ## Creating a schedule 1. Navigate to **Test Development → Test Plans**. 2. Click the test plan you want to schedule. 3. Inside the test plan, click the **Schedules** tab. 4. Click **New Schedule** (or the **Add Schedule** button below the schedule list). 5. The schedule dialog opens. Fill in the following fields: ### Schedule fields **Name** (required) A descriptive label for this schedule. Use names that describe the timing and purpose, for example "Nightly Regression — Staging", "Hourly Smoke — Production", or "Pre-Release Full Suite". **Date** The start date for the schedule. **Time** The start time for the schedule. **Repeat** Select how often the schedule runs: | Repeat | Behavior | | ------------ | --------------------------------------------------------------------------------------------------- | | Don't Repeat | Runs once at the specified date and time | | Hourly | Repeats every hour | | Daily | Repeats every day at the specified time | | Weekly | Repeats every week on the same day (the chip shows the day, for example "Weekly on Friday") | | Monthly | Repeats every month on the same date (the chip shows the day, for example "Monthly on the 8th day") | **Notify** An email address to notify with each scheduled run's result. 6. Click **Save**. The schedule appears in the Schedules tab with its next scheduled run time displayed. {% hint style="info" %} Schedules run in your browser's local timezone, derived from your system settings. There is no separate timezone field to set. {% endhint %} *** ## Viewing scheduled runs **Schedule list:** Navigate to **Test Plans → your plan → Schedules tab**. The Schedules tab uses a split view: the schedule list on the left and a calendar on the right. Each schedule card shows: * An active/paused toggle * Schedule name * Recurrence label (Once / Hourly / Daily / Weekly / Monthly) * Next run time * The notification email, if set * **Run now**, **Edit**, and **Delete** actions **Calendar:** The calendar plots scheduled events on their target dates. Use the previous and next arrows to change months, or click **Today** to return to the current date. You can collapse or expand the schedule list to give the calendar more room. **Across all plans:** Navigate to **Test Plans → Schedules** (the workspace-level Schedules tab) to see schedules across all test plans. This provides a consolidated view for scheduling hygiene — identifying overlapping schedules, dormant schedules that should be deactivated, or gaps in coverage. *** ## Pausing, resuming, and deleting schedules **To pause a schedule:** 1. Navigate to the plan's Schedules tab. 2. Toggle the schedule **off** using the switch on its card. The schedule keeps all its settings. It doesn't run while paused. **To resume a schedule:** Toggle the switch back **on**. The next run time is recalculated from the current time. **To run a schedule immediately:** Click **Run now** on the schedule card to trigger an execution outside the normal cadence. **To edit a schedule:** Click the **Edit** icon on the schedule card to change its name, date, time, repeat frequency, or notification email. **To delete a schedule:** Click the **Delete** icon on the schedule card. 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 must surface failures without anyone manually checking the portal. ContextQA delivers scheduled-run results through email and Slack. ### Email * **Per schedule:** Enter a recipient address in the **Notify** field when you create or edit a schedule. * **Per plan:** On the plan's **Settings** tab, enable **Send Notification** and add recipient email addresses. Each run then sends an email with the result. ### Slack When you connect a Slack workspace for your workspace and enable **Send Notification** on the plan, each run also posts its result to your connected Slack channel. To connect Slack, see the [Slack integration](/integrations/integrations.md) guide. The notification includes the test plan name, the run ID, the overall pass/fail status, pass/fail counts, and a link to the run report in the portal. *** ## Scheduled run best practices ### Smoke tests — run frequently Schedule a lightweight smoke test plan to run **Hourly** 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 Repeat: Hourly Notify: qa-alerts@company.com ``` ### Full regression — run nightly Schedule the full regression test plan to run overnight before your team starts work. Set the **Time** to an off-hours slot (for example, 1:00 AM) and **Repeat** to **Daily**. Every morning then begins with a clear picture of the application's health. ``` Regression Plan — Staging Time: 01:00 Repeat: Daily Notify: qa-team@company.com ``` ### Pre-release verification — run against production Schedule a production verification run to execute after each deployment window. Set **Repeat** to **Daily** at a time shortly after your deployment slot, and pause it during freeze periods. This confirms the deployment did not break critical paths in the live environment. ### Freeze periods Before a planned maintenance window or during a code freeze: 1. Navigate to each active schedule. 2. Toggle the schedule **off**. 3. Document the pause in your team's change log. 4. Toggle schedules back **on** 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 a full regression daily on staging; reserve production runs for pre-release verification. * **Stagger schedules to avoid concurrency conflicts.** If several plans run at the same time, offset their start times so they execute sequentially instead of competing for the same execution slots. * **Review the workspace Schedules tab every sprint.** Schedules accumulate over time. Regularly review the workspace-level Schedules view to deactivate schedules for deprecated features, superseded test plans, 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 email and Slack notifications work as expected. ## Troubleshooting **A scheduled run did not execute at its configured time** Confirm the schedule is active — the toggle on the schedule card must be on. Paused schedules stay saved but don't run. Also confirm the date and time are correct; schedules run in your browser's local timezone. **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 for your workspace and that **Send Notification** is enabled on the plan. If the connection was recently revoked (for example, a Slack workspace admin removed the ContextQA app), re-authorize the integration. Confirm the configured Slack channel still exists and that the ContextQA Slack app can post to it. **I need a schedule that runs at different times on different days** Add multiple schedules to the same test plan. You can create any number of schedules on a plan — for example, one for weekday timing and a separate one for weekend timing. Both appear in the Schedules tab and can be managed independently. ## Related Pages * [Test Plans](/web-testing/test-plans.md) * [Running Tests](/execution/running-tests.md) * [Configuring Environments](/execution/environments.md) * [Managing Test Suites](/web-testing/managing-test-suites.md) * [Integrations](/integrations/integrations.md) {% 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 %} --- # 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://learning.contextqa.com/execution/scheduling.md?ask=&goal= ``` `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.