Skip to main content
Schedules are derived from mission fields and exposed as ScheduleEntry runtime records. The scheduler evaluates due entries no more often than every 30 seconds by default.

Create a schedule

POST /v1/schedules accepts: A one-shot schedule disables its entry after the trigger. If mission execution fails, the mission returns to scheduled and can be registered for automatic retry. After success it remains completed. A recurring mission returns to recurring after either success or failure and computes its next cron occurrence. When endDate is reached, the entry is disabled and the mission transitions to completed.

Cron syntax

Polpo accepts exactly five fields: minute, hour, day of month, month, and day of week. It supports numbers, comma-separated lists, ranges, *, and steps such as */10. Day of week accepts 0-7, with both 0 and 7 meaning Sunday.
Aliases such as @daily, a seconds field, and L, W, or # modifiers are not supported. There is no timezone field on a schedule. Cron evaluation uses the server process timezone. Author Cloud schedules as UTC; self-hosted operators should set and document the server timezone explicitly. An agent identity’s timezone does not affect scheduling.

Manage schedules

PATCH enabled: false disables the in-memory entry without deleting the mission’s expression. Deleting clears the schedule field. Local schedule files are stored in .polpo/schedules/*.json and use the same CreateScheduleRequest shape. polpo deploy sends each file to /v1/schedules.
Project configuration does not expose an enableScheduler setting. Availability is a server runtime concern; do not add settings.enableScheduler to polpo.json.