Schedules
A schedule starts the agent at set times, with nobody present.
Creating one
| Field | What it defines |
|---|---|
| Time | When to start it |
| Time zone | The zone the time is read in |
| Input data | What the agent receives on each trigger |
| If the previous run is still going | See the concurrency policy |
| If a time is missed | See missed triggers |
| Validity | In development, it always expires |
The input data is checked at creation time
If the agent has required fields, the schedule has to supply them — and they are checked against the version it points to, at creation time, with the same preparation as any trigger.
Without that check, an agent with required input could not be scheduled, and the problem would surface in the middle of the night.
If the data needs correcting, there is a dedicated action for it that preserves the time, the policy, and the history. A refused correction does not erase the wrong value — that value is precisely what you need to see in order to fix it.
Time zone
The time is interpreted in the chosen zone, with daylight saving handled correctly.
Concurrency policy
What to do when the time comes and the previous run is still going:
| Policy | Behavior |
|---|---|
| Do not allow | The trigger is skipped |
| Allow | Both runs go in parallel |
| Replace | The previous one is cancelled and the new one starts |
Choose with the effect in mind: a report writing to the same place should not run twice at once.
Missed triggers
When the platform was unavailable at the expected time:
| Policy | Behavior |
|---|---|
| Skip | The missed time is not recovered |
| Run once | One trigger fires on recovery, not one per missed time |
There is no option to recover every missed time: ten hours offline would produce ten simultaneous runs.
Failure from incompatible data
If the input data stops fitting the version it points to, the schedule is flagged with the problem, visible next to it, and moves the time forward so it does not repeat the invalid trigger in a loop.
It is not disabled for that reason. Previously, a data failure counted as a transient failure and the schedule disabled itself — from the point of view of whoever configured it, the daily report simply stopped arriving, with no explanation.
Duration
| Environment | Behavior |
|---|---|
development | Always expires. A forgotten test stops on its own |
production | Durable, until removed |
Changing the version a schedule runs
The schedule points to an exact active version. Publishing a new version does not move it: activate the new version so it starts being run.
Common errors
| Symptom | Cause | What to do |
|---|---|---|
| The schedule does not fire | The version it points to is no longer active | Check the environment's active version |
| It stopped running after a change | The input data no longer fits the version | Fix the schedule's data |
| It ran twice at the same time | "Allow" policy with a long run | Change the policy |
| It ran at an unexpected time | A different time zone than expected | Review the zone |
Next steps
Was this page helpful?
Report a problem on this pageDo not send passwords, keys, tokens, or customer data.