Schedule times and rules

Creating a schedule requires script_id, name, kind, and timezone. Time settings belong in preset. You cannot change a schedule's scenario after creation; create a new schedule for another scenario.

Weekdays run from 0 (Sunday) to 6 (Saturday). Day 31 is not present in every month. For intervals longer than an hour, use a multiple of 60 minutes. Cron follows the calendar; it is not a timer that starts after the preceding run finishes.

Preview

POST /api/v1/schedules/preview accepts the time settings and returns upcoming occurrences. Always inspect them, especially after changing time zones or daylight saving rules. Specify Europe/Moscow explicitly if that is your intended zone; the computer's time zone does not replace this field.

Overlapping runs

overlap_policy can be:

• skip: skip if the previous run is still active;
• queue: add the next run to the queue;
• cancel_previous: stop the previous run and start a new one.

Use window_start and window_end in HH:MM format to limit the execution window. jitter_seconds adds a random shift, up to 1800 seconds in the standard configuration. params supplies scenario parameters.

is_active: false disables the schedule. /pause and /resume control its pause state. The /events history explains the scheduler's actual decision: start, skip, or rejection. Limits and an unavailable agent can still prevent a run even when its time expression is valid.

Retry policy

• retry_policy: "inherit" (default): keep site limits and the shared backoff.
• retry_policy: "never": do not schedule automatic retries.
• retry_policy: "transient": retry transient failures only; requires retry_limit (1–5 additional attempts) and retry_delay_seconds (60–86400).

Trial runs and permanent or unknown failures are not retried. Disabled schedules do not create new retries, but do not cancel retries already queued. timezone_city is an optional display label, up to 120 characters. The required IANA timezone controls calculations; the city name does not.

GET /api/v1/schedules/{schedule} returns recent_runs (up to 5), active_run, preview (up to 5 times) and server_time. This is a snapshot: repeat GET for current state. running means actual execution rather than dispatch. In v2 and UUID mode, nested run identifiers are UUIDs too; v1 without the header retains numeric identifiers.