DEV Community

Cover image for Cron & Scheduled Tasks in Garudust Agent — Autonomous Agents That Run Without You
Garudust
Garudust

Posted on

Cron & Scheduled Tasks in Garudust Agent — Autonomous Agents That Run Without You

#rust #ai #automation #devops

Most AI agents wait. They sit idle until a human types something, respond, then go back to waiting.

Garudust Agent can be different. With garudust-cron, you schedule tasks using standard cron syntax — the agent wakes up, runs a full LLM loop with all its tools, and goes back to sleep. No human required.

This post shows you exactly how to configure it, with the correct syntax pulled straight from the source.

How It Works

garudust-cron is a crate within the Garudust workspace. When a scheduled trigger fires, it calls agent.run(task) — the same code path as a user typing a message. The agent has access to all its configured tools: file read/write, terminal, RAG, web search, and anything else you've enabled.

Cron runs as part of garudust-server. There is no separate daemon.

Three Ways to Set Up Cron Jobs

1. config.yaml — Permanent, survives restarts 

# ~/.garudust/config.yaml
cron:
  jobs:
    - schedule: "0 0 9 * * 1-5"   # weekdays at 09:00 (server timezone)
      task: "Write a morning briefing and append it to ~/briefing.md"

    - schedule: "0 0 18 * * 5"    # Fridays at 18:00
      task: "Summarise this week's git commits and save to ~/weekly.md"
Enter fullscreen mode Exit fullscreen mode

CronJob has exactly two fields: schedule and task. Nothing else.

schedule uses 6-field cron syntax (seconds first):

┌───────── second (0–59)
│ ┌─────── minute (0–59)
│ │ ┌───── hour (0–23)
│ │ │ ┌─── day of month (1–31)
│ │ │ │ ┌─ month (1–12)
│ │ │ │ │ ┌ day of week (0–6, Sun=0)
│ │ │ │ │ │
0 0 9 * * 1-5
Enter fullscreen mode Exit fullscreen mode

Timezone follows the server process — set your system timezone before starting garudust-server if needed.

2. CLI flag or environment variable — One-off / Docker 

# CLI flag — comma-separated "cron_expr=task" pairs
garudust-server --cron-jobs "0 0 9 * * *=Write morning briefing,0 0 18 * * 5=Weekly summary"

# Or via environment variable in ~/.garudust/.env
GARUDUST_CRON_JOBS="0 0 9 * * *=Write morning briefing"
Enter fullscreen mode Exit fullscreen mode

These take precedence over config.yaml when both are set.

3. Runtime via chat — No restart needed

Once the server is running, you (or any admin) can create jobs live by asking the agent:

You:   Create a cron job that runs every day at 7am to check disk usage
       and send me an alert if any partition is above 80%.

Agent: [uses cron_create tool]
       Created cron job 'disk_check' with schedule: 0 0 7 * * *
Enter fullscreen mode Exit fullscreen mode

Note: cron_create uses 6-field cron syntax (seconds first): sec min hour dom month dow
Same format as config.yaml.

Format Where used Example
6-field everywhere (config.yaml, --cron-jobs, env var, cron_create) 0 0 9 * * 1-5

Runtime jobs are not persisted — they disappear on server restart. Add them to config.yaml for permanent schedules.

Manage runtime jobs:

You:   List all active cron jobs.
Agent: - [disk_check]  schedule: 0 0 7 * * *  task: Check disk usage...  created: 2025-05-21 07:00 UTC

You:   Delete the disk_check job.
Agent: Cron job 'disk_check' removed.
Enter fullscreen mode Exit fullscreen mode

Memory Maintenance (Bonus)

CronConfig has two extra fields specifically for automatic memory housekeeping:

cron:
  jobs:
    - schedule: "0 0 9 * * *"
      task: "Morning briefing"

  # Consolidate and deduplicate memory entries
  memory_consolidation: "0 0 3 * * *"   # daily at 03:00

  # Expire stale memory entries (based on memory_expiry settings)
  memory_expiry: "0 0 4 * * 0"          # weekly on Sunday at 04:00
Enter fullscreen mode Exit fullscreen mode

These run lightweight maintenance tasks — no LLM call required.

Practical Examples

Morning Briefing 

cron:
  jobs:
    - schedule: "0 0 8 * * 1-5"
      task: >
        Write a morning briefing covering: (1) any new files in ~/inbox/,
        (2) a summary of yesterday's ~/logs/app.log errors,
        (3) today's date and day of week.
        Save the result to ~/briefing/$(date +%Y-%m-%d).md.
Enter fullscreen mode Exit fullscreen mode

Log Monitoring 

cron:
  jobs:
    - schedule: "0 */15 * * * *"   # every 15 minutes
      task: >
        Check /var/log/app/error.log for entries in the last 15 minutes.
        If there are more than 10 errors, append a summary to ~/alerts/errors.log.
Enter fullscreen mode Exit fullscreen mode

Weekly Git Summary 

cron:
  jobs:
    - schedule: "0 0 17 * * 5"   # Fridays at 17:00
      task: >
        Run git log --since="1 week ago" --oneline in ~/project/,
        summarise what changed by area, and save to ~/reports/weekly.md.
Enter fullscreen mode Exit fullscreen mode

Sending Results to Telegram

Cron jobs have no built-in delivery mechanism — the agent writes to files or uses tools. To send to Telegram, write it into the task prompt:

cron:
  jobs:
    - schedule: "0 0 9 * * *"
      task: >
        Write a morning briefing (top 3 priorities for today, weather summary).
        Then send it to Telegram chat ID 123456789 using the send_message tool.
Enter fullscreen mode Exit fullscreen mode

The agent calls send_message itself. The chat ID must be hardcoded in the task or retrievable from a file the agent can read.

Disabling Cron Tools

If you want to prevent the agent from creating or deleting jobs at runtime, disable the toolset:

disabled_toolsets: [cron]
Enter fullscreen mode Exit fullscreen mode

Config-file jobs still run — only the cron_create / cron_list / cron_delete runtime tools are disabled.

Summary

config.yaml --cron-jobs / env var Runtime (cron_create)
Cron syntax 6-field 6-field 6-field
Persists across restarts ✅ ❌ ❌
Requires restart to activate ✅ ✅ ❌
cron_list shows it ❌ ❌ ✅

Start with config.yaml for anything you want running reliably. Use runtime jobs for experiments or tasks you only need for the current server session.

Garudust Agent — GitHub · Releases

Top comments (3)

Collapse
 
singh_coder profile image
Harpinder •

Nice. Having cron call the same agent.run(task) path as a normal prompt feels like the right base primitive.

One thing I'm curious about: where do you draw the line between cron and source-event triggers?

A weekday briefing at 9am feels like cron. But something like wake when a billing email arrives, or when a calendar event with an external attendee is created, feels more like a watch/filter that should only wake the agent on a match.

I'm building Watchline around that second shape, so I'm curious whether you see Garudust handling those as scheduled jobs that inspect tools, or eventually exposing a more explicit event/watch layer too.

Collapse
 
garudust profile image
Garudust •

Current Garudust architecture:

The cron path is straightforward: CronScheduler → agent.run(task, "cron") — no filter condition, just a time tick that
fires. All other event entry points today are platform messages through GatewayHandler and the webhook adapter, both of
which receive a raw InboundMessage and hand it directly to the LLM. There is no structured filter layer anywhere.

Direct answer on cron vs. watch:

There is no watch primitive today. If you wanted "wake when a billing email arrives" with the current architecture, you
have two options:

  1. Cron poll — a job every N minutes, agent checks the inbox and decides. Wasteful and adds latency.
  2. Push via webhook — an external system (e.g. Watchline) pushes the event to the webhook platform adapter, GatewayHandler calls agent.run(). But the filter logic lives in the caller, not in Garudust.
Collapse
 
singh_coder profile image
Harpinder •

yeah, that's the split i'd care about too. cron is fine for time ticks; once the caller owns the filter, you're already halfway to a watch layer. i'd probably want a small trigger envelope upstream so GatewayHandler sees a normalized event + context instead of a raw message.

that's basically the bit i'm building Watchline around. curious what would have to exist for you to make that a first-class primitive instead of leaving it in the caller.