Scheduled Runs
Use scheduled runs to execute saved scripts on a fixed cadence without manual dispatch.
Path: App -> Schedules
Create a schedule
Section titled “Create a schedule”- Open
/app/schedules. - Choose script and target agent.
- Enter a cron expression and timezone.
- Set guardrails:
- max runtime minutes
- max retries
- retry delay seconds
- concurrency limit
- idempotency window minutes
- Save.
Default runtime is 12 hours (720 minutes). Schedules can be configured up to 22 hours (1320 minutes) when a workflow legitimately needs a longer timeout.
Configure variables and vault keys
Section titled “Configure variables and vault keys”- Put non-secret inputs in
variables(JSON object). - Put secret inputs in
vaultKeysso the scheduler injects decrypted values at runtime. - Missing vault keys block dispatch for that run.
Trigger behavior
Section titled “Trigger behavior”The scheduler evaluates due rows and applies these controls before dispatch:
- organization billing gate
- concurrency limit per schedule
- idempotency window
- agent readiness (including auto-start when stopped/offline)
If checks pass, Mimic dispatches a job and writes schedule metadata (lastRunAt, lastRunStatus, nextRunAt).
Manual and dry-run execution
Section titled “Manual and dry-run execution”Use POST /api/schedules/execute for scoped manual execution.
Example:
{ "dryRun": false, "force": true, "scheduleId": "sched_abc123", "limit": 1}Rules:
force: truerequiresscheduleId.dryRun: truereports what would trigger without dispatching jobs.- Manual runs now return detailed
triggeredSchedules,skipped, anderrorsdata so the UI can show lock contention, agent readiness, or vault problems directly.
Cron worker endpoint
Section titled “Cron worker endpoint”Use GET or POST /api/cron/scheduled-runs with x-cron-key (or bearer token) set to CRON_SECRET.
Recommended:
- run every minute
- include
dryRun=truein non-production smoke checks - alert on repeated executor lock errors
Operating model
Section titled “Operating model”- Keep deterministic selectors and explicit assertions to preserve RPA-first reliability.
- Use retries for transient portal failures only.
- Use stale-job watchdog endpoints alongside schedules to keep queues recoverable.