Functional Testing: Schedules
Overview
Use this page to create and manage cron-based schedules for functional test runs. A schedule runs a chosen project of a functional testing package automatically at times you set with a cron expression, instead of you starting that project by hand every time it needs to run. This solves the problem of keeping a regression or smoke package running on a predictable cadence, such as nightly or before business hours, without anyone needing to remember to start it.
A schedule depends on a package and project that already exist in Functional Testing: Packages, and can optionally use engines and engine tags from Functional Testing: Engines to control where it runs, a gold image version to control what build it runs on (see Testing: Gold Images (sign-in required)), and Testing-scope alert profiles from Alerting: Profiles to notify someone when a run ends Failed or Unfinished. Once a schedule fires, its runs show up in Functional Testing: Run History alongside manually started runs.
On this page you create, edit, enable or disable, run immediately, and delete schedules. A Table view lists every schedule with its next and last run, while an Upcoming view groups the runs the next 7 days of enabled schedules will start, by day, so you can see what is about to run at a glance.
Key concepts
- schedule - A saved configuration that runs a specific project of a functional testing package automatically on a cron expression, instead of you starting it manually each time. (related: Functional Testing: Packages)
- cron expression - A five-field pattern (minute hour day month weekday) that defines exactly when a schedule's timer fires.
- Testing-scope alert profile - An alert profile scoped to Testing that a schedule can link so a Failed or Unfinished run notifies someone automatically. (related: Alerting: Profiles)
- Upcoming view - A view of this page that lists, grouped by day, every run the enabled schedules will start in the next 7 days.
When to use it
- To automate a recurring functional testing run, such as a nightly regression or hourly smoke check, instead of starting it from Run Test by hand each time.
- To review, before a release window, exactly which runs will fire in the next 7 days across every schedule, using the Upcoming view.
- To link Testing-scope alert profiles so a schedule's Failed or Unfinished run notifies someone automatically.
- To pause a schedule during a maintenance window by clearing Enabled, without losing its configuration.
- To trigger an existing schedule's run immediately with Run now, outside its normal cron time.
Before you begin
- At least one functional testing package with a project exists (Functional Testing: Packages); a schedule always runs a project inside a package.
- If you want to restrict runs to specific capacity, the engines and engine tags you need are already configured (Functional Testing: Engines).
- If you want scheduled failures to notify someone, a Testing-scope alert profile already exists (Alerting: Profiles).
- Your role has permission to create and edit schedules; otherwise the dialog opens read-only and row actions are disabled.
Common workflows
Create a cron schedule for a functional project
Persona: load-test operator automating a regression package
- Click Add schedule.
- Expect: The create-schedule dialog opens with the Daily 02:00 cron preset, Enabled and Headless browsers already checked.
- Choose a Package and then a Project.
- Expect: The Project list populates for the chosen package; any previously ticked testcases clear.
- Leave Testcasesuntouched, or tick specific ones.
- Expect: The dialog keeps 'run every runnable testcase' unless you tick individual rows.
- Set the Cron expression (pick a preset or type your own) and the Time zone.
- Expect: The Cron expression field updates to the chosen pattern; the schedule will fire by this time zone's clock.
- Tick any Alert profiles (Testing scope) to notify on failure, then click Save.
- Expect: The dialog closes and the new schedule appears in the Table view with a computed Next run time.
Verify: The new schedule's row shows the correct Package, Project and a Next run time that matches the cron expression and time zone you set.
Review and trigger this week's scheduled runs early
Persona: operator preparing for a release window
- Click Upcomingabove the schedule list.
- Expect: The view switches to a day-by-day list of every run the enabled schedules will start in the next 7 days.
- Find the run you want to pull forward and click its Run now.
- Click Open the runin the status message.
- Expect: You're taken to the run's detail record.
Verify: The run appears in Functional Testing: Run History with a start time matching when you clicked Run now, not its originally scheduled time.
Steps
Step 1
Open Schedules under Functional Testing.
Expected result: The page loads in its empty state: a calendar icon and the message 'No schedules yet. Click Add schedule to run a project on a cron expression.' appear in place of the table, with the Add schedule button above it.
This is the starting point for automating a functional testing project instead of starting it by hand every time.
- Add schedule opens the create-schedule dialog.
- The intro line above the button notes that linked Testing-scope alert profiles are evaluated only when a scheduled run ends Failed or Unfinished.
Tabs on this page
-
Table- The default view: a flat list of every schedule with its package, project, next run, last run and last verdict, plus row actions. Switch to it to manage schedule configuration.
- Name, Package, Project, Next run, Last run, Last verdict, and the Enabled toggle.
-
Upcoming- Lists the runs the enabled schedules will start in the next 7 days, grouped by day (Today, Tomorrow, then the weekday name) in the appliance's time zone. Switch to it to see what is about to run across all schedules at a glance.
- Day grouping, run time, schedule name, package, project, Run now.
Field reference
| Field | Purpose | Format / Validation | Required | Default |
|---|---|---|---|---|
| Name | Identifies the schedule in the table and Upcoming view; pick a name that tells you what it runs and how often so you can recognize it later. | text | Yes | - |
| Package | Selects which functional testing package the schedule runs; changing it reloads the Project list and clears any testcases ticked for the previous package. | dropdown (first 100 packages) | Yes | - |
| Project | Selects which project inside the chosen package the schedule runs; a package can define more than one project, so this narrows the run to one. | dropdown, populated after Package is chosen | Yes | - |
| Testcases | Limits the run to specific testcases; leave none ticked to run every runnable testcase in the project, or tick individual testcases to run only a subset, such as a fast smoke subset instead of the full suite. | checklist, one row per testcase with its type | No | none ticked (runs every runnable testcase) |
| Engine | Pins the schedule to run on one specific engine instead of letting engine tags decide placement; leave it blank to let tag matching choose any available engine at run time. | dropdown | No | - |
| Engine tags (all required) | Restricts the schedule to engines carrying every listed tag; add more tags to narrow placement to a smaller, more specific pool of engines, or leave it empty to allow any engine. | multi-select | No | - |
| Cron expression | Sets exactly when the schedule fires, as five space-separated fields (minute hour day month weekday); use a preset for a common cadence or type a custom expression for anything else. | text, 5-field cron syntax | Yes | 0 2 * * * |
| Time zone | Determines the zone the cron expression's hours are evaluated in; set it to the zone your operations are planned in so a time like 02:00 actually fires at 2 AM where you expect, not in the appliance's default zone. | text (IANA or Windows time zone id) | No | the appliance's current time zone |
| Ok threshold (%) | Sets the minimum pass percentage a run needs to avoid being treated as failed; raise it to require nearly all testcases to pass before alerting, lower it to tolerate some failures in a noisier suite. | number (percent) | No | 100 |
| Max run time (minutes) | Caps how long a scheduled run may execute before it is stopped and marked Unfinished; raise it for long end-to-end suites, lower it to catch runs that hang instead of occupying an engine indefinitely. | number (minutes) | No | 120 |
| Enabled | Controls whether the cron expression fires at all; clear it to pause a schedule, for example during a maintenance window, without deleting its configuration, then set it again to resume on the same cadence. | checkbox | No | checked |
| Headless browsers | Chooses whether scheduled runs use headless browser engines (no rendered UI) rather than full browsers; headless is faster and uses less engine capacity, full browsers render closer to what a real user sees but run slower. | checkbox | No | checked |
| Alert profiles (Testing scope) | Links Testing-scope alert profiles so they are evaluated when the schedule's run ends Failed or Unfinished; link more profiles to notify more teams, or none to run silently with no automatic alerting. | checklist, multi-select | No | none linked |
| Gold image | Optionally pins the schedule's runs to one gold image version. | picker (version list) | No | newest at start time |
Column reference
| Column | What it shows | How to read it |
|---|---|---|
| Name | The schedule's name, as entered in its dialog. | Schedules are listed alphabetically by this name. |
| Package | The functional testing package the schedule runs. | Shows '(deleted package)' when the package backing the schedule has been removed; edit the schedule to pick a replacement. |
| Project | The project within the package that the schedule runs. | Matches the Project selected in the schedule's dialog. |
| Next run | The next time the schedule's cron expression will fire. | Still populated even when the Upcoming view is unavailable; a schedule with Enabled cleared shows no next run. |
| Last run | The timestamp of the schedule's most recently completed run. | Blank until the schedule has fired, or been run with Run now, at least once. |
| Last verdict | The outcome of the schedule's most recent run. | Failed or Unfinished are the outcomes that trigger any linked Testing-scope alert profile; any other outcome completed without alerting. |
Controls reference
Add schedule
Opens the create-schedule dialog with defaults already filled in (Daily 02:00 cron preset, Enabled and Headless browsers checked, Ok threshold 100, Max run time 120).
When to use: Use it the first time you want a project to run automatically instead of being started by hand.
Side effects: Read-only until you save; no schedule exists until Save completes.
Cron presets
Fills the Cron expression field with a ready-made pattern for a common cadence (Hourly, Daily 02:00, Weekdays 07:00, Weekly Mon 06:00).
When to use: Use a preset instead of hand-writing cron syntax for a standard cadence; type a custom expression only when none of the presets match.
Side effects: Only changes the dialog's Cron expression field; nothing is saved until you click Save.
Every testcase
Clears every ticked testcase, returning the schedule to running all runnable testcases in the project.
When to use: Use it to undo a partial testcase selection without unticking each one by hand.
Side effects: Dialog-only change; takes effect once you save.
Unlink
Removes a stale alert-profile id from the schedule's linked Alert profiles selection.
When to use: Use it when a previously linked Testing-scope alert profile no longer qualifies, so the schedule would otherwise fail to save.
Side effects: Dialog-only change; the removal is written only when you save the schedule.
Save
Creates the schedule if it's new, or updates it if you opened an existing one, using the dialog's current field values.
When to use: Use it once all required fields (Name, Package, Project, Cron expression) are filled in.
Side effects: Mutating: writes the schedule and closes the dialog on success; shows 'Couldn't save the schedule' with a reason on failure.
Close
Closes the dialog without saving any changes.
When to use: Use it to discard the dialog without creating or changing a schedule.
Side effects: Read-only; no schedule is created or changed.
Run now (table)
Starts a run of the schedule immediately, outside its normal cron time.
When to use: Use it to run a schedule on demand, for example to verify a change before its next scheduled fire time.
Side effects: Mutating: starts a run right away; the row shows a busy state while it starts.
Run now (Upcoming)
Starts an immediate run of the schedule shown in that Upcoming row, the same as the Table view's Run now.
When to use: Use it from the Upcoming view when you are already reviewing the week's runs and want to start one early.
Side effects: Mutating: starts a run right away.
Enable / disable toggle
Flips the schedule's Enabled state directly from the table row, without opening the dialog.
When to use: Use it to pause or resume a schedule's cron firing, for example during a maintenance window.
Side effects: Mutating: disables (or re-enables) the schedule immediately; a disabled schedule shows no Next run.
Edit / View
Opens the schedule's dialog pre-filled with its current configuration.
When to use: Use it to change any field of an existing schedule, or, if your role cannot write schedules, to review its configuration read-only.
Side effects: Read-only until you save; the button is labelled View instead of Edit when your role's grants refuse the update.
Delete
Opens a confirm dialog and, once confirmed, removes the schedule permanently.
When to use: Use it when a schedule is no longer needed; this removes only the schedule, not the package or project it ran.
Side effects: Mutating and irreversible: the schedule and its cron firing are permanently removed once confirmed.
Table / Upcoming view switch
Switches the page between the flat schedules table and the Upcoming view that groups the next 7 days of runs by day.
When to use: Use Upcoming to see what will actually run this week across all schedules at a glance; use Table to manage schedule configuration.
Side effects: Read-only; switching to Upcoming re-reads that view's runs each time you open it.
Open the run
Navigates to the triggered run's detail record.
When to use: Use it from a status message after Run now, to inspect that run's progress or results.
Side effects: Read-only; navigates away from the Schedules page.
Alerting → Profiles
Navigates to the Alerting profiles page.
When to use: Use it when the Alert profiles (Testing scope) list has no suitable profile yet and you need to create one.
Side effects: Read-only; navigates away from the Schedules page.
Retry
Reloads the schedules after a failed read.
When to use: Use it when the page shows 'Couldn't load the schedules'.
Side effects: Read-only; re-runs the load.
Dismiss
Closes the status banner shown after an action such as Run now or a save.
When to use: Use it once you've read the status message and want it out of the way.
Side effects: Read-only; does not affect the schedule itself.
Verify the result
A successfully created schedule appears as a row in the Table view with its Name, Package and Project filled in, and a Next run time computed from its Cron expression and Time zone. Once it has fired at least once, by its cron time or via Run now, Last run and Last verdict populate with the most recent result. Switching to the Upcoming view shows that same run grouped under the correct day if it falls within the next 7 days. If the row instead shows '(deleted package)' or no Next run time, the schedule's package was removed or the schedule is disabled; check the Package field and the Enabled toggle first.
Troubleshooting
- Symptom: Saving the schedule fails with a message naming an alert profile. Fix: one of the linked Alert profiles (Testing scope) is no longer a Testing-scope profile; click Unlink on it and link a valid one, or leave the field empty.
- Symptom: The dialog shows 'The package no longer exists; pick another one.' Fix: the schedule's original package was deleted in Functional Testing: Packages; choose a replacement Package before saving.
- Symptom: A schedule's Package column reads '(deleted package)'. Fix: edit the schedule and pick a replacement package, or delete the schedule if the automated run is no longer needed.
- Symptom: The Upcoming view reports it cannot list upcoming runs yet. Fix: the appliance is on an older build that predates the Upcoming feature; keep using the Table view's Next run column until it is updated.
- Symptom: Row actions (Run now, the Enabled toggle, Delete) are disabled, or Edit shows as View only. Fix: your role's grants don't include changing schedules; ask an administrator to grant Functional Testing schedule write access.
Related articles
- Prerequisite: Functional Testing: Packages - a package and project must exist before a schedule can run one
- Prerequisite: Functional Testing: Engines - defines the engines and tags a schedule can be pinned to
- See also: Testing: Gold Images (sign-in required) - the gold image versions a schedule can pin its runs to
- Prerequisite: Alerting: Profiles - Testing-scope alert profiles must exist before a schedule can link them
- Next step: Functional Testing: Run History - shows the runs a schedule has started
- See also: Functional Testing: Dashboard - surfaces overall functional testing activity including scheduled runs