Overview
MeepaGateway has a built-in cron system that runs agent tasks on a schedule. Each job sends a message to an agent (triggering the full agent loop) and optionally delivers the response to a specific connector and channel. Jobs are stored per-agent in SQLite and survive restarts. The scheduler uses a next-wake model: it sleeps until the earliest due job (capped at 60 seconds) rather than polling continuously.Schedule Types
Every
Fixed interval:
"30m", "2h", "1d". Runs repeatedly at the given interval.Cron
7-field cron expression with seconds:
"0 0 9 * * 1-5 *". Full calendar control.At
One-shot: fires once at a specific UTC datetime. Use
delete_after_run = true to clean up automatically.Configuration
Cron jobs are defined per-agent inconfig.yaml:
Job Options
Unique job name within the agent.
The prompt sent to the agent when the job fires. This is the agent’s input — not the final message delivered to users. The agent processes it through the full loop and the response goes to
delivery.One of:
{ every = "30m" }— fixed interval (supportss,m,h,d){ cron = "0 0 9 * * 1-5 *" }— 7-field cron with seconds{ at = "2025-07-01T09:00:00Z" }— one-shot RFC 3339 datetime
Where to post the agent’s response. If omitted, the response is discarded (useful for jobs that write to memory or trigger side effects).
Enable or disable the job without removing it.
Delete the job after its first successful execution. Useful for one-shot jobs.
Override the agent’s default model for this job.
Override the agent’s
max_iterations for this job.Per-job execution timeout (e.g.
"2m").Restrict execution to a UTC hour range. Format:
[start_hour, end_hour] (0–23). Jobs that fall outside this window are skipped and retried at the next scheduled time.Cron Expression Format
MeepaGateway uses a 7-field cron format with seconds as the first field:| Expression | Meaning |
|---|---|
0 0 9 * * 1-5 * | Weekdays at 9:00 AM UTC |
0 */30 * * * * * | Every 30 minutes |
0 0 0 1 * * * | First day of each month at midnight |
0 0 8,12,18 * * * * | 8 AM, noon, 6 PM daily |
Managing Jobs at Runtime
Jobs can be created, updated, and deleted via the Captain Dashboard or API without restarting the gateway.Captain API
Failure Recovery
The scheduler tracksconsecutive_failures per job. Failed jobs are retried at the next scheduled time. There is no exponential back-off — the schedule drives retry timing.
Jobs that exceed their timeout are killed and counted as failures. The scheduler does not block waiting for a failed job; other due jobs continue to fire independently.
Architecture
CronStore— per-agent SQLite store for job definitions, run history (last_run_at,next_run_at), and failure countsCronScheduler— unified scheduler across all agent stores; uses a next-wake model (sleeps until earliest due job, capped at 60s)- When a job fires, its
messageis dispatched through the same agent loop as a regular incoming message, withdeliverycontext set for the response
