Skip to main content

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 in config.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 (supports s, 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:
Examples:

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 tracks consecutive_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 counts
  • CronScheduler — unified scheduler across all agent stores; uses a next-wake model (sleeps until earliest due job, capped at 60s)
  • When a job fires, its message is dispatched through the same agent loop as a regular incoming message, with delivery context set for the response