Wiki · Start here
Scheduled tasks (cron)
A morning brief, a nightly check, hourly monitoring — delivered where you chat with the agent.
⏰
Anything done over and over should do itself.
A summary arrives in the morning, a check runs at night, a website is watched every hour. The result lands where
you chat with the agent — usually Telegram or Discord. Nothing is scheduled silently:
you always confirm a job before it is created.
What you can schedule
| Job | How often | What it gives you |
|---|---|---|
| Morning brief | daily at 7:30 | A short message: what happened in your field, what is urgent, what today holds |
| Website check | every hour | Speaks up only when the site stops answering — silent otherwise |
| News collection | every 2 hours | New articles from the feeds you care about |
| Post-deploy check | once | Verifies the change really went live |
| Monthly summary | 1st of the month | What was done, what it cost, what is next |
| Nightly tidy-up | every night at 3:00 | Triage the task queue or prepare material for the morning |
Three ways to create a job
- Say it in the conversation. The easiest route — it works even if you have never heard
of scheduled jobs:
❯ Every weekday at eight in the morning send me a summary of AI news. ❯ Every hour check that our website responds, and only write to me if there is a problem.The agent asks for the details and creates the job.
- With an explicit schedule. One line when you know what you want:
# inside a chat $ /cron add "every 2h" "Check the server and write to me only if something is wrong." # from the command line $ hermes cron create "every 1d at 09:00" "Send me today's plan and three priorities."
- From a ready-made blueprint. Common tasks have templates — fill in a few fields and
you never touch a schedule format:
$ /blueprint morning-briefAvailable blueprints include a morning brief, uptime monitoring, news collection, deploy verification, dependency security audits and nightly backlog triage.
How schedules are written
| Notation | Meaning |
|---|---|
every 5m / every 2h | every 5 minutes / every 2 hours |
every 1d at 09:00 | once a day at 9:00 |
every 1d at 07:30 | once a day at half past seven |
| in words: "every weekday at eight" | works too — the agent translates it |
Times are evaluated in the server's time zone. If the server runs on your local time (the usual setup), "morning" means exactly what you expect.
Where the result goes
To wherever you chat with the agent — Telegram, Discord or another connected platform. If a job has nowhere to deliver, it still runs but the output is lost; the job reports that as a delivery failure, so you can spot it in the job list.
A job can also stay silent. When the agent decides there is nothing to report (all is well),
it answers with [SILENT] instead of a message and nothing is sent. That is why prompts like
"write to me only if there is a problem" work so well.
What must hold for it to work
| Condition | Why, and what to do |
|---|---|
| The gateway must be running | The scheduler is part of it and checks every minute what is due. With the gateway down, jobs do not fire — check hermes cron status |
| The prompt must be self-contained | Every run starts with a clean head: the job sees neither your conversations nor previous runs. It cannot refer to "what we discussed yesterday" — put everything it needs into the prompt |
| There must be model credit | A job consumes the model just like a normal conversation (see choosing a model) |
| The server must be awake | With the machine off, nothing runs. The agent notices missed runs and can catch up, but the missed time is gone |
Useful commands
| Command | What it does |
|---|---|
hermes cron list | Lists every job with how its last run went |
hermes cron status | Tells you whether the scheduler is alive and when the next run is |
hermes cron doctor | Checks the jobs and reports problems (undelivered output, repeated failures) |
hermes pause and hermes resume | Emergency stop for all jobs, and starting them again |
/cron inside a chat | Review and manage jobs without leaving the conversation |
Tips from experience
| Tip | Why |
|---|---|
| Give jobs a cheap model | They run often and unattended, so the cost adds up. Set cron.model to send them to a cheaper model than the one you chat with |
| Write specific prompts | What to check, from where, who it goes to, how long it should be. "Make a summary" turns out differently every time |
| Short message, long output as a file | A few sentences suit a phone; have a table attached as a file instead |
| Let the job stay silent when all is well | Alerts that always arrive stop being read — which is worse than none |
| Check on it occasionally | hermes cron list shows whether the job really runs and what it sends |
| Nothing irreversible unattended | A job runs while you are away. Deletions, payments or messaging people belong behind manual approval |
When it does not work
| Symptom | Cause and what to do |
|---|---|
| Nothing arrived | Start with hermes cron status — is the scheduler alive? Then hermes cron list to see whether the job is paused and how the last run went |
| The run happened but no message came | The job has nowhere to deliver (platform not connected) or the send failed. The list reports it as a delivery failure |
| It fires too often or at the wrong time | Check the schedule notation and the server's time zone |
| The job mixes up context | The prompt refers to a conversation or a previous run that the job cannot see. Add every needed detail to the prompt |
| I want it to stop | Pause or delete one job in /cron; hermes pause stops all of them at once |