How to Schedule and Recover Hermes Agent Cron Jobs

Steps

1. 1

   Prove the task and gateway work

   Run the task once interactively, then check hermes doctor, hermes gateway status, and hermes cron status. Fix provider, tool, credential, or gateway failures before adding a schedule.

2. 2

   Choose agent, hybrid, or script-only mode

   Use an agent job for research, judgment, writing, browser work, or publishing. Use --no-agent --script filename for a deterministic script under ~/.hermes/scripts/. Use a pre-check script without no-agent when the script should wake the LLM only after a change.

3. 3

   Write a self-contained future prompt

   Cron agent runs start in fresh sessions. Include source paths, URLs, constraints, output format, failure behavior, and the proof of success. Do not rely on phrases such as 'the usual report.'

4. 4

   Create a supported schedule

   Use hermes cron create "0 9 * * 1-5" "<prompt>" --name "Weekday brief" for a weekday 9am job. Hermes also supports relative delays (30m), intervals (every 2h), and ISO timestamps.

5. 5

   Set an absolute project workdir

   Add --workdir /absolute/path/to/project for repository work. Hermes then loads supported project instruction files and points terminal, file, and code tools at that directory. Relative or missing directories are rejected.

6. 6

   Attach only needed skills and toolsets

   Add repeatable --skill flags for reusable procedures. Configure the cron platform in hermes tools, or ask Hermes to set per-job enabled_toolsets, so routine jobs do not carry unnecessary browser, terminal, or delegation access.

7. 7

   Confirm provider and model behavior

   Hermes snapshots the active provider/model when the job is created and fails closed after an unexpected global default change. The standalone create command does not expose provider/model flags, so ask Hermes in chat to pin those advanced job fields when needed.

8. 8

   Pin exact delivery

   Use --deliver local, telegram, discord, or an exact target such as telegram:-1001234567890:17585. For Slack, use slack:C0123456789 for a channel ID, slack:#engineering for a discovered channel name, or slack:U0123456789 for a DM. Invite the bot and prefer raw IDs for unattended work.

9. 9

   Trigger one run and inspect the outcome

   Run hermes cron run "Weekday brief", wait for the next scheduler tick, then inspect hermes cron list, hermes cron runs "Weekday brief" --limit 20, local output, and the exact destination. A completed ledger row is useful evidence, but the delivered message or artifact is the final proof.

10. 10

    Add silence, continuation, or chaining deliberately

    Use [SILENT] for successful agent no-op runs, empty stdout for script-only silence, attach_to_session for a replyable brief, and context_from for explicit upstream-output handoffs. These are opt-in behaviors, not shared memory.

11. 11

    Know the recovery commands

    If provider limits or bad delivery create repeated failures, use a normal shell: hermes cron pause <id-or-name>, fix the provider/gateway/target, trigger a test, then hermes cron resume <id-or-name>. Use remove only when the job should be deleted.

12. 12

    Classify the failure layer

    Run hermes gateway status, hermes cron status, hermes cron list, and hermes cron runs <job> --limit 20. Separate schedule lifecycle, execution result, delivery error, and intentionally silent output before changing the job.

13. 13

    Check timezone and repeat state

    Cron expressions use the scheduler host's local timezone. Relative delays and ISO timestamps are one-shot; intervals and five-field expressions recur. A completed job may simply have exhausted its finite repeat count.

14. 14

    Recover with a controlled rerun

    Pause a noisy or consequential recurring job, fix one failing layer, trigger one test, and verify the external destination or artifact before resuming. Reconcile any unknown run first so a rerun cannot duplicate side effects.

15. 15

    Pin reasoning effort when useful

    Use hermes cron edit <job> --reasoning-effort high|minimal to give complex and routine jobs different thinking budgets. The pin is user-owned and does not apply to no-agent jobs.

Pro Tips

• 💡Use cron expressions for exact wall-clock schedules and intervals such as every 2h for cadence-based work.
• 💡Agent jobs run in fresh sessions; keep procedures in skills and make every prompt self-contained.
• 💡CLI-created jobs default to local delivery, while messaging-created jobs normally default to origin.
• 💡Script-only jobs save model tokens: non-empty stdout delivers, empty stdout stays silent, and failures alert.
• 💡Use a hybrid pre-check script with {"wakeAgent": false} when frequent polls rarely need reasoning.
• 💡Set a workdir for repo jobs; otherwise project instructions and the intended cwd are not automatic.
• 💡Pin important reports to an exact chat, topic, thread, or channel and verify the first delivery.
• 💡Pause noisy jobs from a normal shell if the interactive provider is rate-limited.
• 💡The dashboard is a checkpoint; the delivered message or artifact is the success proof.
• 💡Use continuable delivery only for briefs that need follow-up, and context_from only for explicit job pipelines.

Troubleshooting

FAQ

Related setup and cost guides