The schedule channel triggers a pipeline according to a defined calendar. It's the equivalent of a cron, but configured in the model editor and logged like every other exchange.
Why this channel
Not all pipelines are reactive (to an email, a call, a webhook). Many are proactive: daily report, weekly follow-up, hourly check of an external system. That's what the schedule channel covers.
Configuration
- In the model editor, configure the Start node with a Scheduled trigger receiver.
- Choose:
- Calendar — build it visually with the CronBuilder (daily, weekly or monthly, at the time of your choice), or switch to advanced mode to enter a classic 5-field cron expression (
0 8 * * 1-5= 8am on weekdays). No knowledge of cron syntax required. - Timezone — IANA name (
Europe/Paris,UTC…) in which the calendar is interpreted. Default:UTC. - Objective — a free label (e.g.
briefing_hebdo,alerte_impayes) passed to the pipeline to route it. - On missed tick — the catch-up policy (
catchup), see below. Default: catch up all.
- Calendar — build it visually with the CronBuilder (daily, weekly or monthly, at the time of your choice), or switch to advanced mode to enter a classic 5-field cron expression (
One pipeline, several objectives. The same Start can carry several scheduled triggers, each with a different objectif. Conditions (filter) at the start of the pipeline then steer execution according to the objective received — for example a weekly briefing on Monday and a daily alert in the same template (see CFO IA).
What the pipeline receives
On each trigger, an exchange is created with:
schedule.objectif— the configured objective label (for multi-trigger routing)schedule.cron— the configured cron expressionschedule.occurrence— the planned timestamp (UTC)schedule.fired_at— the actual trigger timestamp (UTC)schedule.catchup—trueif this trigger is a catch-up
Tolerance & catch-up
Each trigger is placed in a durable queue before being executed: a restart during execution does not lose it.
If betool is unavailable at the moment of a trigger (maintenance, incident), what happens to missed occurrences depends on the trigger's On missed tick setting (catchup):
| Choice | Value | Effect |
|---|---|---|
| catch up all (default) | all | Missed occurrences are replayed, within a 24-hour window and limited to the 12 most recent. |
| most recent only | run_once | Only the most recent missed occurrence is replayed. |
| none | skip | No missed occurrence is replayed; the pipeline resumes at the next scheduled trigger. |
A caught-up occurrence is executed only once and marked schedule.catchup = true, which lets the pipeline flag a report produced late. An occurrence deliberately skipped (run_once, skip) is skipped for good: it does not come back later, even if you change the policy afterwards.
Beyond the 24-hour window, nothing is replayed: a missing report is better than an avalanche of late reports. A trigger that has never run yet has nothing to catch up.
Choose most recent only for a point-in-time state (synchronisation, check) where only the latest run matters, and none when a late run would no longer make sense (hourly alert, reminder at a fixed time).
Typical use cases
- Daily report at 8am — an agent that queries several systems, summarizes and sends a brief by email.
- Hourly sync — a pipeline that pulls new items from an external system, passes them to a classifier agent, and pushes the results into your CRM.
- Weekly check — an agent that audits the state of an infrastructure and flags discrepancies.
- D+7 follow-up — on leads submitted a week ago and still without a response.
Best practices
- Avoid on-the-minute starts — many systems pulse at
0 * * * *. Prefer7 * * * *to spread the load. - Log tasks that have nothing to do. A task that runs but does nothing (because there are no items to process) must trace this explicitly. Otherwise, you won't be able to tell "all is well" from "the task no longer runs".