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
string
required
Unique job name within the agent.
string
required
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.object
required
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
object
Where to post the agent’s response. If omitted, the response is discarded (useful for jobs that write to memory or trigger side effects).
boolean
default:"true"
Enable or disable the job without removing it.
boolean
default:"false"
Delete the job after its first successful execution. Useful for one-shot jobs.
string
Override the agent’s default model for this job.
integer
Override the agent’s
max_iterations for this job.string
Per-job execution timeout (e.g.
"2m").array
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: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
