How-To Guide
Schedule Hermes Agent Cron Jobs That Actually Deliver
Schedule Hermes Agent cron jobs safely: natural-language schedules, script-only monitors, pinned Telegram/Discord delivery, rate-limit avoidance, dashboard checks, and recovery when a morning brief or publishing job fails.
Quick answer
Use Hermes cron for scheduled agent work that needs judgment, tools, memory, and delivery. Use script-only `no_agent=true` jobs for quiet deterministic monitors. Pin the profile, workdir, schedule, skills/toolsets, and exact Telegram/Discord/email/file destination, then run it once immediately and verify the real delivered output. If cron reliability depends on VPS uptime, provider credits, gateway restarts, and dashboard monitoring, compare the managed FlyHermes path before making self-hosting your operations burden.
Hermes has a built-in cron scheduler that understands natural language — tell it 'every morning at 9am, check Hacker News and send me a summary on Telegram' and it creates a scheduled agent run. The operational lesson from recent community threads is sharper: the job is not successful when it is merely scheduled. It is successful when the report, alert, file, commit, or live URL appears in the exact destination you intended.
Managed cloud · API costs included · Skill library · Cancel anytime
Before you start:
- ☑Hermes Agent installed and able to complete one CLI smoke test from the same profile that will run the job
- ☑A persistent runtime: launchd/systemd, Docker, a VPS, or managed FlyHermes if the job must run while your laptop sleeps
- ☑The delivery channel already tested once, such as a Telegram DM/topic, Discord channel/thread, email target, or file output path
- ☑Provider credits, API keys, and fallback route checked before scheduling repeated LLM-heavy work
- ☑If using script-only mode, a local script under the expected workdir that exits cleanly and prints only the alert/report you want delivered
Steps
- 1
Prove the agent works before scheduling it
Run `hermes doctor` and one tiny `hermes chat -q "reply cron ok"` test from the same profile, model provider, and workdir the cron job will use. Fix API-key, credit, or rate-limit errors before blaming the scheduler.
- 2
Choose LLM-driven or script-only mode
Use a normal Hermes cron job when the run needs judgment, writing, research, browser/tool use, or publishing. Use a script-only `no_agent=true` job when a deterministic local script can print nothing on success and only send an alert on failure.
- 3
Write a self-contained future prompt
Assume the future run has no memory of the chat that created it. Include the goal, repo or file paths, source-of-truth links, exact output format, delivery target, and success condition such as a sent report, saved file, passing test, committed change, or live URL.
- 4
Pin schedule, profile, workdir, skills, and toolsets
Create the schedule with natural language such as `every weekday at 9am` or a cron expression like `0 9 * * *`, then pin the active profile, workdir, and required skills/toolsets so a future run does not execute in the wrong project.
- 5
Pin the delivery destination explicitly
Important recurring jobs should deliver to a specific Telegram chat/topic, Discord channel/thread, email, or file path. Avoid vague origin delivery for daily business workflows because the original chat can move, expire, or be the wrong forum topic.
- 6
Run it once immediately
Trigger the job once after creation. Check `hermes cron list` or `hermes cron status`, inspect logs, and confirm the exact destination received the result. A green scheduler state is not enough; delivered output is the proof.
- 7
Use the dashboard as a checkpoint, not the proof
Open `hermes dashboard` to inspect profile, provider, memory, tools, cron, logs, and gateway state. Then still verify the actual Telegram, Discord, file, GitHub, or production URL output that the job was created to produce.
- 8
Add rate-limit and recovery rules
For daily reports, content publishers, and gateway alerts, tell the job what to do if the provider hits 402/429, the gateway is draining, or a deploy is delayed. Prefer concise failure reports over silent partial success.
- 9
Decide when FlyHermes should own the uptime
If the job is business-critical and the hard part is VPS uptime, Docker restarts, Telegram/Discord delivery, provider keys, and monitoring, compare FlyHermes before turning cron reliability into another server-maintenance project.
Pro Tips
- 💡For scheduling to work reliably, Hermes must run continuously — use PM2 ('pm2 start hermes') or Docker to keep it alive
- 💡You can schedule with natural language: 'every weekday at 8am' or 'every Sunday at 7pm' — no cron syntax needed
- 💡Chain tasks: set a morning digest that pulls from email, GitHub, and calendar into one Telegram message
- 💡A scheduled agent job should prove completion with a report, alert, commit, published URL, or explicit no-op, not just say it ran.
- 💡Use script-only no_agent jobs for quiet deterministic monitors and LLM-driven cron jobs for judgment-heavy scheduled work.
- 💡Pin important cron delivery to an explicit Telegram topic, Discord channel, email, or file path instead of relying on vague origin delivery.
- 💡For deterministic monitors, prefer no_agent=true scripts that print nothing unless an alert is needed.
- 💡For publishing or research jobs, require a live URL, saved artifact, sent report, or passing test before the job can report success.
- 💡For quiet monitors, prefer script-only no_agent jobs that print nothing unless a threshold is crossed.
- 💡If the cron delivers to Telegram or Discord, verify the exact chat, forum topic, thread, or channel after the first run.
- 💡Use the Web UI to inspect cron/profile/gateway state, but use delivered output as the proof; the optional --tui browser Chat tab is for local debugging, not a cron success condition.
- 💡For Obsidian updates, cron jobs should append dated summaries and read back changed files instead of silently rewriting large notes.
- 💡Use the Hermes dashboard/Web UI as a status checkpoint, but verify success with the real command, channel message, cron delivery, or deployed URL that matters.
- 💡Fresh evidence note (2026-06-28): Discord support threads named `Woke up and no morning brief = Sad Panda`, `Cron Job Bug`, and gateway/tool failures show that schedule creation, provider health, and delivery routing must be verified separately.
- 💡Fresh social note: Reddit and YouTube discussions about 17-hour agent sessions, agent dashboards, and monitor tools show that scheduled agents need observability, not just a cron expression.
- 💡Before declaring the workflow fixed, open the private Hermes dashboard, select the correct profile, check provider/model/gateway/cron state, and then verify the real channel or scheduled delivery path.
Troubleshooting
❌ Scheduled task doesn't run at the expected time
✅ Check your timezone setting in config.yaml. Hermes uses UTC by default if no timezone is set, which may cause time offset issues.
❌ Hermes misses schedules after server reboot
✅ Ensure Hermes is set to auto-start on boot. With PM2: 'pm2 startup && pm2 save'. With Docker: use '--restart unless-stopped'.
❌ Scheduled notification arrives but message is empty
✅ The scheduled task may have hit a tool error silently. Check logs around the scheduled time, verify tool output, and make the job report a concise failure instead of sending an empty success.
❌ Cron job says it succeeded but Telegram or Discord received nothing
✅ Check the explicit delivery target, allowed chat/channel/thread, gateway process state, and platform permissions. Then send one manual test message or run the job once into the exact target.
❌ Morning brief or publishing job misses runs during provider outages
✅ Separate provider fallback from scheduling. Verify API credits, auxiliary model routes, retry behavior, and a cheap/script-only fallback path where possible.
❌ The job runs in the wrong repository or profile
✅ Pin workdir and profile in the job definition, and include absolute source paths in the prompt. If the job edits content, require git diff, tests, and live URL verification before success.
FAQ
How do I schedule a task in Hermes?
Tell the built-in cron scheduler in natural language, e.g. 'every morning at 9am, check Hacker News and send me a summary on Telegram.' Hermes parses the schedule and runs it unattended.
Do scheduled jobs run if my laptop is asleep?
Only if the host is awake. Cron jobs need Hermes running, so for reliable scheduled runs put the agent on an always-on server or managed host rather than a laptop that sleeps.
Why didn't my morning brief run?
Usually the host wasn't running Hermes at the trigger time, the provider hit a rate limit, or the gateway was down. Check that the agent process is alive and the channel is connected at the scheduled time.
Related setup and cost guides
Cron jobs deep dive
Use this article for LLM-driven vs script-only job design, delivery proof, and publishing-job success criteria.
Hermes dashboard and Web UI
Inspect cron state, active profile, provider, tools, logs, and gateway health before debugging a missed run.
Gateway troubleshooting
Use this when a scheduled report runs but Telegram, Discord, or another channel does not receive the message.
Provider costs and rate limits
Use this when cron jobs fail with 402/429, exhausted credits, auxiliary model errors, or provider fallback issues.
FlyHermes managed path
Compare self-hosted cron/gateway upkeep with managed browser, mobile, channel, and uptime operations.