Local scheduler

What this accomplishes

Schedule workflows with cron on your machine — no per-trigger cloud fees.

The local scheduler is the scheduler that runs the user’s workflows on a schedule. The scheduler runs on the user’s machine; the scheduler uses the tokio-cron-scheduler under the hood; the scheduler supports missed- fire backfill. The scheduler is the right shape for users who want to run workflows on a schedule without paying a per-trigger fee.

This page is the local scheduler. The blog post on the scheduler is at local scheduler vs cloud cron; the webhook receiver is in webhook receiver; the run inspector is in run inspector and replay; the dry-run mode is in dry-run mode.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build, an active project and Automation open.
• A connected model plus permission for every file, network or scheduled action in the workflow.

The cron expressions

The local scheduler uses standard cron expressions. A cron expression has five fields: minute, hour, day of month, month, day of week. The expressions support the standard operators (*, */n, n-m, n,m, n/m).

Examples:

• 0 9 * * 1-5 — at 9:00 AM, Monday through Friday.
• */15 * * * * — every 15 minutes.
• 0 0 1 * * — at midnight on the first day of every month.
• 0 9 * * 1 — at 9:00 AM every Monday.

The expressions are validated at save time by constructing the underlying job — an invalid expression is rejected with an error rather than silently accepted.

The missed-fire backfill

The scheduler catches up on runs it missed while your machine was off or asleep. At boot, it looks for scheduled fires whose time passed in roughly the last 15 minutes and replays them, then resumes its normal cron ticks from there.

This is a single global setting, not a per-workflow one: Settings → Workflow scheduler has a “Skip missed runs on boot” toggle. Off (the default) replays missed runs once when Miton starts again; on drops them. There is no per-workflow backfill window and no burst-limiting of how many missed runs replay at once.

The cost model

The scheduler itself has no per-trigger fee. You pay the model cost when a run calls a model, and whatever the machine costs to keep running — there’s no separate charge per scheduled fire. A workflow with no model node (a pure data transform, an HTTP fetch, a file move) costs nothing to run beyond that.

What the local scheduler does not cover

The local scheduler does not cover:

• Hosted execution — the local scheduler runs on the user’s machine; the scheduler does not run on a Miton-operated host.
• Multi-tenant execution — the local scheduler is single-tenant. The scheduler does not run multiple tenants on the same machine.
• Cross-machine scheduling — the local scheduler runs on a single machine. A user who has multiple machines can configure the scheduler to run on each machine independently.

The local scheduler focuses on the per-machine scheduling. The less common cases are covered by the user’s existing tools.

What success looks like

The local scheduler is the right shape for a user who has well-understood workflows and wants to run them on the user’s own machine. The cost model is the model’s cost, not a per-trigger fee. The infrastructure is the user’s machine, not a hosted service.

Leave “Skip missed runs on boot” off unless a workflow’s missed runs would do more harm replayed late than skipped — the default replays what was missed while Miton was closed.

Common failures and recovery

• Inspect the failed run and the exact node output before replaying it.
• Confirm credentials, permissions and test fixtures belong to the active project.
• Use a dry run to isolate a misconfigured node before starting the complete workflow again.

Related next action

Open the Automation overview to connect this task to the rest of the workflow.