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 also support the standard shortcuts:

• @hourly — at the top of every hour.
• @daily — at midnight every day.
• @weekly — at midnight every Sunday.
• @monthly — at midnight on the first day of every month.
• @yearly — at midnight on January 1.

The expressions are validated at save time. An invalid expression is rejected with a clear error message.

The missed-fire backfill

The missed-fire backfill is the feature that catches up on missed runs when the user’s machine is offline. When the scheduler starts (or recovers from a pause), it checks for missed runs; for each missed run, it triggers the workflow as if the scheduled time had just passed.

The missed runs are flagged in the run history as “missed-fire catchup” so the user can distinguish them from regular runs. The missed-fire backfill is configurable; the user can set a backfill window (e.g. “backfill the last 24 hours”, “backfill the last 7 days”, “do not backfill”) in the workflow’s settings.

The default backfill window is 24 hours. The user can disable the backfill per workflow; the user can also configure a longer window (7 days, 30 days) for workflows that are time-sensitive.

The missed-fire backfill is rate-limited. A user who has been offline for a week does not get all 168 missed runs at once; the user gets a burst of up to 10 runs, then the rest are scheduled at the workflow’s normal rate. The rate limit prevents the user’s machine from being overwhelmed by the backfill.

The rate limiting

The rate limiting is the feature that prevents a workflow from being triggered too frequently. The rate limit applies per workflow; the rate limit is a per-workflow configuration.

The rate limit is configured in the workflow’s settings. The user can set a minimum interval between runs (e.g. “no more than once per minute”, “no more than once per hour”). The rate limit is enforced by the scheduler; the rate-limited runs are skipped, not queued.

The rate limit is useful for workflows that should not be triggered more frequently than a certain interval. A user who has a workflow that posts to a chat channel can set the rate limit to “no more than once per hour” to prevent the channel from being flooded.

The cost model

The local scheduler has no per-trigger fee. The user does not pay Zapier’s per-task fee, Make’s per-operation fee, or n8n Cloud’s per-execution fee. The user pays the model cost (if the workflow calls the model) and the electricity cost (the machine is on while the workflow runs).

A user with 100 workflows running hourly for a month has 72,000 workflow runs in the month. On Zapier, at $0.0001 per task, the cost is $7.20. On Make, at $0.01 per operation, the cost is $720. On Miton, the cost is the model cost (typically $0.001 to $0.01 per run, depending on the model and the prompt length), which is $0.72 to $7.20. The model cost is the variable cost.

A user with workflows that do not call the model (the workflow is a pure data transform, an HTTP fetch, a file move) pays $0 for the workflow runs. The workflow runs on the user’s machine; the remaining cost is the electricity cost.

The comparison to Zapier, Make, and n8n

The local scheduler is not a Zapier replacement in every dimension. The comparison:

• Zapier has a larger integration catalogue (5,000+ apps); Miton has a smaller catalogue (the built-in nodes plus the user’s MCP servers). Zapier has a hosted execution environment; Miton has a local execution environment. Zapier has a multi-tenant model; Miton has a single-tenant model. Zapier is the right choice for a user who needs the integration catalogue; Miton is the right choice for a user who needs local execution.
• Make is similar to Zapier. Make is a hosted service; Make has a per- operation fee; Make has a larger integration catalogue. Make is the right choice for a user who needs the integration catalogue; Miton is the right choice for a user who needs local execution.
• n8n is open-source; n8n can be self- hosted; n8n has a per-execution fee on the cloud tier. Miton’s local scheduler is a self-hosted option with a smaller catalogue and a tighter focus on Chat, Writer, Canvas, Code, and Automation.

The local scheduler is the right shape for the user who has a small set of well-understood workflows, who wants to run them on the user’s own machine, who does not want to pay a per-trigger fee, and who is willing to maintain the workflow definitions.

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.

Use the missed-fire backfill as a safety net. The default 24-hour window is a good starting point. A user who has workflows that are time-sensitive (scheduled reports, deadline-driven actions) should set a longer window; a user who has workflows that are not time-sensitive (cleanup tasks, low-priority notifications) can leave the default.

Use the rate limiting to prevent a workflow from being triggered too frequently. The rate limit is per workflow; the rate limit is a per-workflow configuration.

The local scheduler is not a Zapier replacement in every dimension. If the user needs a large integration catalogue, Zapier is the right choice. If the user needs hosted execution, Zapier or Make is the right choice. If the user needs a self-hosted scheduler with a smaller catalogue and tighter focus, Miton is the right choice.

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 dry-run or step replay before starting the complete workflow again.

Related next action

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