Configure Windmill schedules to run scripts and flows automatically. The guide explains schedule file naming, Windmill’s six-field cron format including seconds, and CLI commands for listing, pulling, or explicitly pushing schedule changes.
MUST use when configuring schedules.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Schedules run scripts and flows automatically on a cron schedule.
Schedule files use the pattern: {path}.schedule.yaml
Example: f/folder/daily_sync.schedule.yaml
Note: The path is derived from the filename, not stored in the file content.
Windmill uses 6-field cron expressions (includes seconds):
┌───────────── second (0-59)
│ ┌───────────── minute (0-59)
│ │ ┌───────────── hour (0-23)
│ │ │ ┌───────────── day of month (1-31)
│ │ │ │ ┌───────────── month (1-12 or jan-dec)
│ │ │ │ │ ┌───────────── day of week (0-6, 0=Sunday, or sun-sat)
│ │ │ │ │ │
* * * * * *
Common Examples:
0 0 0 * * * - Daily at midnight0 0 12 * * * - Daily at noon0 */5 * * * * - Every 5 minutes0 0 9 * * 1-5 - Weekdays at 9 AM0 0 0 1 * * - First day of each monthDeploying local changes to the workspace can be destructive to remote state — only suggest/run a deploy when the user explicitly asks to deploy/publish/push, not when they say "run", "try", or "test". Deploy via git push or wmill sync push depending on how the repo is wired (see the Deploying section in AGENTS.wmill.md). The commands below never mutate remote state, so they're safe to run yourself — note that sync pull does overwrite local files to match the remote (use sync pull --dry-run to only preview), while schedule just lists.
# Push schedules to Windmill — only when the user explicitly asks to deploy
wmill sync push
# Pull schedules from Windmill
wmill sync pull
# List schedules
wmill schedule
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Plan the code changes needed to add a TriggerCrud-based trigger to Windmill. The checklist covers backend, database, API, CLI, frontend, capture, and validation work so the new trigger can be managed across the product.
Improve Windmill’s AI chat by reviewing its tools, prompts, result shapes, and context usage. The guidance helps place shared instructions where chat and CLI can use them, reduce repeated token costs, and compare behavior before and after changes with A/B evaluations.
Create and run black-box benchmarks for Windmill AI generation modes such as flows, apps, scripts, CLI, and global requests. Each case exercises the production path, checks hard requirements, and uses an LLM judge to assess user-facing behavior before and after changes.
Use this reference to work with Windmill resources from the command line, including scripts, flows, datatables, and workspace settings. It also covers listing jobs, inspecting details and logs, retrieving results, and rerunning or restarting executions when investigating failures.
Use this skill to shape modules with small interfaces and substantial behavior behind them. It helps you decide where a seam belongs, reduce complexity exposed to callers, and make code easier to test and maintain.
Use this skill to review pending changes, select only the relevant files for staging, and create a focused Git commit. It formats the single-line message with a Conventional Commits type such as feat, fix, or docs, and checks the resulting status.