Scheduled Tasks

12.1. Scheduled Tasks — Running Jobs on a Schedule

Syntax for creating a cron job

hermes cron create "0 9 * * 1" "Compile the weekly report" --deliver telegram
/cron add "every 2h" "Check server status"

Both standard cron syntax (0 9 * * 1) and natural language (every 2h, hourly) are supported — no need to memorize traditional cron syntax if you are not used to it.

Managing a job’s lifecycle

hermes cron list
hermes cron pause <job_id>
hermes cron resume <job_id>
hermes cron edit <job_id>
hermes cron delete <job_id>

Jobs fully support pause/resume/edit — no need to delete and recreate them for every small adjustment.

The most important principle: isolated sessions, no conversation memory

Every cron run is a completely fresh session that does not inherit the previous conversation — this is the core difference from a normal interactive chat. A job’s prompt must be self-contained (“what to do”, “by which criteria”, “in what format”) — you cannot write “do it like yesterday”, because the agent has no memory of “yesterday” in the context of a cron session.

Validation before real runs

Hermes validates a job’s configuration before executing it: if an API key is missing, a required skill is missing, or the delivery target is wrong, the job moves to a blocked_config state and sends exactly one warning — not repeated on every tick, avoiding spam while still making sure you know there is a problem.

Notes

• Always run once manually (manual trigger or dry-run) before letting a job run fully automatically — avoid discovering formatting/logic errors only after days of quietly running wrong.
• Periodically run hermes cron list to check for blocked_config states — because the warning is only sent once, it is easy to miss if you do not proactively review.
• For important jobs, write the prompt in full detail as if instructing someone who knows nothing about the prior context — because that is, in essence, exactly the situation.