Appearance
Schedules
Last updated
The Schedules page runs an existing workflow, script, ladder task action or transaction group at set times, using a cron expression. It is the recommended way to put anything on a clock: one page lists every timed job with its last run.
Open Schedules in the Visualize section of the sidebar — Run workflows, scripts, ladder tasks and transaction groups on a cron schedule.
Report emails are scheduled separately, on the Reports page.
Creating a schedule
- Click New Schedule. (Or, on the Workflows list, click a workflow's calendar button — the form opens with the action, target and a name like Run Press fault notification already filled in.)
- Name — e.g. Nightly OEE snapshot.
- Action — see the table below.
- Target — pick from Select…. No targets of this type exist yet. means you need to create one first.
- Schedule — build the timing (below).
- Click Save Schedule. New schedules start enabled.
| Action | Runs |
|---|---|
| Run Workflow | The workflow; a disabled workflow fails with Workflow "…" is disabled |
| Run Script | The script |
| Start Ladder Task | Starts scanning the task |
| Stop Ladder Task | Stops the task |
| Execute Transaction Group | One execution of the group |
Save Schedule stays grayed out until Name, Target and Schedule are filled in. An invalid cron is refused with Invalid cron expression.
The schedule builder
| Mode | Settings | Cron produced |
|---|---|---|
| Every N minutes | every 1–59 minutes | */15 * * * * |
| Every N hours | every 1–23 hours, at minute 0–59 past | 5 */2 * * * |
| Every day | at a time | 0 6 * * * |
| Weekly (on days) | tick Mon–Sun, at a time | 30 22 * * 1,2,3,4,5 |
| Monthly (day of month) | on day 1–31, at a time | 0 7 1 * * |
| Custom cron… | type the expression | anything valid |
The default for a new schedule is every day at 08:00 (0 8 * * *).
Cron syntax
Five fields separated by spaces: minute hour day-of-month month day-of-week.
| Field | Range | Notes |
|---|---|---|
| minute | 0–59 | |
| hour | 0–23 | 24-hour clock |
| day of month | 1–31 | |
| month | 1–12 | Numbers only, no JAN/FEB |
| day of week | 0–7 | 0 and 7 are Sunday; numbers only, no MON/TUE |
Each field can be * (any), a number, a range 8-17, a list 0,30, or a step */10 or 8-17/2. Seconds, L, W, # and ? are not supported. When both day of month and day of week are restricted, the schedule fires when either matches (standard cron rule): 0 6 1 * 1 fires on the 1st and on every Monday.
| Cron | Runs |
|---|---|
*/5 * * * * | Every 5 minutes |
0 6,14,22 * * * | At each shift change: 06:00, 14:00, 22:00 |
55 5 * * 1-5 | 05:55 Monday to Friday |
0 0 * * 0 | Midnight between Saturday and Sunday |
30 6 1 * * | 06:30 on the 1st of each month |
*/10 7-18 * * 1-6 | Every 10 minutes from 07:00 to 18:50, Monday to Saturday |
How schedules fire
- Times are in the appliance's local time zone (the operating system's setting, not the browser's). Around a daylight-saving change, a job in the hour that is skipped or repeated may be skipped or run twice.
- The scheduler checks every 30 s and fires each schedule at most once per matching minute. A job for 06:00 starts between 06:00:00 and about 06:00:30.
- If the appliance is off or restarting during the matching minute, that run is missed. Nothing catches up afterwards.
- Schedules do not wait for each other. A slow workflow still running when its next time comes will run twice at once.
- A scheduled workflow receives only
{{trigger}}=schedule. Schedules cannot pass parameters. If a workflow needs a value, have it read a tag, or schedule a script that callsworkflows.run(name, params).
The schedule list
Each row shows an enable toggle (Enabled — click to disable / Disabled — click to enable), the name, the cron, the action and target, and last run …. The buttons are Run now (fires the action immediately, independent of the cron), Edit and Delete (asks Delete schedule "…"?).
An error badge appears when the last run threw an error — for example a script that failed or a deleted target — and a Scheduled Task Failed notification is shown.
Warning: For Run Workflow, a workflow that runs and fails is still recorded as a successful schedule run, with no error badge. Always check the workflow's own History (or the Failed Last Run count on the Workflows page) rather than trusting the schedule row.
Who can use it
Anyone who can open the page sees the schedules. Creating, editing, enabling, deleting and Run now need the Admin or Editor role.
| Method | Path | Purpose |
|---|---|---|
| GET | /api/schedules | List schedules |
| GET | /api/schedules/targets | Possible targets for each action |
| POST | /api/schedules | Create (name, cron, actionType, targetId, enabled) |
| PUT | /api/schedules/:id | Update any of those fields |
| DELETE | /api/schedules/:id | Delete |
| POST | /api/schedules/:id/run | Run now |
actionType is one of workflow, script, ladder_start, ladder_stop, transaction_group.
Schedules page or Schedule trigger node?
| Schedules page | Schedule trigger node | |
|---|---|---|
| Alignment | Checked every 30 s, once per matching minute | Cron checked every 60 s from when the workflow was saved; can skip or repeat a minute |
| Interval in milliseconds | No (minimum 1 minute) | Yes |
| Last run and errors visible | Yes, one list for everything | Only in each workflow's History |
| Stops when the workflow is disabled | Yes; each run fails with Workflow "…" is disabled | Yes |