Scheduling recurring tasks in AI agent workflows

When you build an AI agent that does something useful — summarises documents, monitors a feed, sends a report, syncs data — you eventually hit the same question: how do I make it run on a schedule? Not once, triggered manually. On a schedule, reliably, while I'm not watching.

The answer sounds obvious: cron job. But cron jobs for AI agents have a specific set of failure modes that traditional scheduled tasks don't. This post walks through the problem and how to solve it cleanly.

Why AI agent scheduling is different

A traditional cron job runs a deterministic script. It succeeds or it fails. You can usually tell which from the exit code or the output.

An AI agent run is different in three ways:

• Variable duration. The same agent task might take 8 seconds or 4 minutes depending on the model, the input, and whether any tools needed retries. A fixed timeout either kills legitimate runs or hides runaway ones.
• Partial success. The agent might complete three out of four steps before failing silently on the fourth. The job exits 0 but the work wasn't done.
• Downstream dependencies. Other systems may be waiting on the agent's output. If the agent run is delayed or skipped, nothing downstream fires — and nothing alerts you.

These failure modes make it worth thinking carefully about how you schedule agents, not just whether you schedule them.

The scheduling options

There are three common approaches, each with different tradeoffs.

Option 1: Platform-native cron (Vercel, Railway, Render)

If your agent runs as a serverless function or a hosted service, the platform usually offers built-in cron scheduling. You configure a schedule, the platform sends an HTTP request to your endpoint at the right time.

This works until it doesn't. Platform cron has no execution history, no alerting on failure, and no guarantee of exactly-once delivery. If the platform retries the request — which it will, eventually — your agent runs twice. For idempotent tasks that's annoying. For tasks that send emails or process payments, it's a bug.

Option 2: A queue with a scheduler

A more robust approach: a dedicated scheduler posts a message to a queue at the scheduled time. A worker pulls from the queue and runs the agent. Whoever pulls the message first wins — the message is gone, so no second worker can pick it up.

This gives you exactly-once semantics via atomic queue operations. Redis BRPOP is the classic implementation: it blocks until a message arrives, then removes it and returns it to exactly one caller. Ten workers can be waiting — only one gets the job.

The tradeoff is operational overhead: you need a queue, a scheduler, and workers, all running and monitored. For a single agent this is usually overkill.

Option 3: HTTP-based scheduling with execution history

The approach that works well for most agent deployments: an external scheduler sends an HTTP POST to your agent's endpoint on the schedule you define. The scheduler logs every execution — request headers, response status, response body, duration, whether it ran on time.

When the run fails, you have the full record: what was sent, what came back, how long it took. When runs stop happening, you get an alert. This is what Tickstem provides.

curl -X POST https://api.tickstem.dev/v1/jobs \
  -H "Authorization: Bearer $TICKSTEM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "daily-summary-agent",
    "url": "https://your-app.com/agents/daily-summary",
    "schedule": "0 8 * * *",
    "timeout_secs": 300
  }'

The scheduler fires a POST to your endpoint at 08:00 every day. Your endpoint runs the agent and returns when it's done. The execution — status code, response body, duration — is recorded and available in the dashboard or via API.

Wiring it up with the MCP server

If you're building with Claude Code or another MCP-compatible agent, Tickstem exposes its scheduling tools natively via MCP. The agent can register its own cron jobs without leaving the editor:

# In your MCP client configuration
{
  "mcpServers": {
    "tickstem": {
      "command": "tsk-mcp",
      "env": { "TICKSTEM_API_KEY": "your-key" }
    }
  }
}

With the MCP server running, the agent can call create_job, list_jobs, and get_executions as native tools. No context switching, no separate dashboard visit to wire up the schedule.

Handling variable agent duration

Set timeout_secs generously. For an agent that usually takes 30 seconds but occasionally takes 3 minutes on heavy inputs, a 60-second timeout generates false failures. Start at 5-10x your typical duration, then tighten once you have execution history data to work from.

Tickstem records the actual duration of every run. After a week of executions, you'll have a realistic p99 — use that as your timeout baseline.

Pairing scheduling with heartbeat monitoring

Scheduling tells you when the agent starts. It doesn't tell you whether the agent actually completed the work it was supposed to do.

For that, add a heartbeat ping at the end of the agent's task — after all the real work is finished, not before. If the ping stops arriving, something went wrong inside the run even though the HTTP response was 200.

# At the end of your agent's task handler
curl -s -X POST https://api.tickstem.dev/v1/heartbeats/$HEARTBEAT_TOKEN/ping

Scheduling + heartbeat together give you the full picture: the scheduler confirms the agent was invoked on time, the heartbeat confirms it did what it was supposed to do. See heartbeat monitoring for background jobs for the full pattern.

A note on exactly-once for agents

Most agent tasks are not naturally idempotent. Sending a summary email twice, creating a duplicate report, or processing the same input twice are real problems. If you're using platform-native cron, add an idempotency check in your endpoint — a database flag, a Redis key, or a content hash — before the agent does anything irreversible.

If you're using Tickstem's scheduler, the queue-backed execution model handles this at the infrastructure level. One schedule tick, one message, one execution.

Related: Heartbeat monitoring for background jobs — pair scheduling with heartbeats to confirm the work actually completed. Also: Production monitoring for Claude Code apps · Why cron jobs fail on serverless. See the cron scheduling tool →