AI Agent Cron Jobs with Hermes Agent: Scheduling Real Work Without Breaking Your Setup

Hermes Agent is not only a chat interface. One of its highest-leverage features is the built-in cron scheduler: you can ask Hermes to run a job tomorrow morning, every weekday, every hour, or on a normal five-field cron expression, then deliver the result to Telegram, Discord, email, or another configured channel.

That changes the shape of an AI assistant. Instead of waiting for you to remember the task, Hermes can wake up, gather context, make a decision, write the report, and send the output while you are doing something else.

If you are comparing cron-style agent automation to workflow builders, see Hermes Agent vs n8n. The short version: n8n is better for deterministic app plumbing; Hermes cron jobs are better when each run needs judgment, memory, tools, and a verified written result.

What Hermes Cron Jobs Are#

A Hermes cron job is a scheduled agent run. It has four important pieces:

1. Schedule — natural language like every weekday 9am, a duration like 30m, or a cron expression like 0 9 * * *.
2. Prompt — the self-contained instruction the future agent run should follow.
3. Delivery target — where the result goes, such as the original chat, a Telegram home channel, a Discord channel, or local output files.
4. Optional runtime controls — skills, toolsets, scripts, model overrides, workdir, and whether the job should run as an LLM agent or as a script-only watchdog.

The key detail: scheduled runs execute in fresh sessions. They do not automatically inherit the context of the chat where you created them, so the prompt must include the full job description, relevant paths, output format, and success criteria.

Two Modes: Agent Jobs vs Script-Only Watchdogs#

Hermes supports two useful cron patterns.

1. LLM-driven cron jobs#

Use this when the task needs judgment. Examples:

• Research a market every morning and summarize only meaningful changes.
• Review recent GitHub issues and decide which ones are urgent.
• Check competitor pages and turn differences into a short action memo.
• Draft a blog post from current release notes and commit it to a website repo.

In this mode, the scheduler starts an agent with the prompt, tools, skills, and working directory you configured. The agent reasons, calls tools, and produces a human-readable final answer.

2. no_agent script-only jobs#

Use this when the logic is deterministic and the script itself can print the exact message to deliver. Examples:

• Disk usage watchdog.
• API health checker.
• Price threshold alert.
• Build-status monitor.
• Feed poller that stays silent unless something changed.

In script-only mode, Hermes runs the script and delivers non-empty stdout verbatim. Empty stdout means silent success. That is perfect for watchdogs: no spam when nothing happened, immediate alert when a threshold trips.

Why Cron Is Different From Reminders#

A reminder says, “Remember to check this.” A Hermes cron job can check it for you.

For example, a normal reminder might say: “At 9am, look for content ideas.” A useful Hermes cron job says:

Every day at 9am, inspect the Hermes Agent repo changelog, recent commits, GitHub issues, Discord notes, and existing website content. Pick one publishable topic, write a new SEO article, add it to /Users/antoine/work/agent-hermes/src/data/blog-posts.json, run npm run build, commit, push, and send the live URL plus verification notes.

That is a production job, not a nudge. The job definition includes the source of truth, publishing path, build command, and delivery format.

A Good Daily Content Cron Prompt#

For website publishing, make the future run impossible to misunderstand:

Daily Hermes Agent website content job. Repository: /Users/antoine/work/agent-hermes. Site: https://hermes-agent.ai/.

Goal: publish one new useful page or article every run, not merely generate a report.

Workflow:
1. Pull latest main.
2. Inspect recent Hermes Agent release notes, commits, issues, docs, and existing site data.
3. Choose one topic that is not already covered and has search intent.
4. Add or update the relevant JSON content source under src/data/.
5. Run npm run build.
6. Commit and push.
7. Verify the live URL or report the deployment blocker with exact command output.

Final message: live URL, topic, files changed, tests run, and next recommended topic.

Notice the phrase “publish one new useful page or article every run.” Without that, a cron job can accidentally become a research report generator. For content operations, the deliverable is the page.

Copy-Paste Cron Job Patterns#

Here are practical patterns to start from.

Daily executive brief#

Every weekday at 8am, review my configured email, calendar, GitHub notifications, and important project notes. Send a concise Telegram brief with: today's meetings, urgent messages, blocked projects, and the three highest-leverage actions.

Website publishing job#

Every morning, inspect the website repo, recent product changes, search-intent backlog, and existing articles. Publish one useful SEO page, run formatting/interlinking/build checks, commit, push, and send the live URL plus verification output.

Silent watchdog#

Every 15 minutes, run the health-check script. If everything is healthy, print nothing. If an endpoint fails twice in a row, print a short alert with the service name, failing URL, status code, and suggested first command to debug it.

These examples are intentionally specific. A vague scheduled prompt creates vague reports. A production cron prompt names the source of truth, desired output, verification steps, and delivery channel.

Delivery Targets Matter#

Cron delivery can be sent to the origin conversation, a home channel, or an explicit platform target. For important daily business workflows, explicit delivery is safer than relying on the origin chat.

Good examples:

• deliver: telegram — send to the configured Telegram home channel.
• deliver: origin — send back to the chat where the job was created.
• deliver: telegram:<chat_id>:<thread_id> — send to a specific Telegram group topic.

If a daily report is important, pin it to the exact destination and verify the next run.

Use workdir for Real Projects#

For repository work, set the cron job working directory to the repo path. If you are setting up the machine first, start with the Hermes Agent install guide so the scheduler can run continuously. That lets Hermes load project-specific instructions from files like AGENTS.md or CLAUDE.md, and ensures terminal/file tools start from the right root.

For a Next.js SEO site, that means the scheduled agent sees the project rules before editing, runs commands in the correct directory, and does not accidentally publish to a similarly named repo.

Verification Checklist#

A good scheduled publishing job should verify all of this before it reports success:

• The new slug exists in the source data.
• The site builds locally.
• The change is committed and pushed.
• The sitemap includes the new URL.
• The live page returns a 200 after deployment.
• The final Telegram/Discord message includes the URL, not just “done.”

For daily content operations, “script refreshed successfully” is not success. “New page is live at this URL” is success.

Common Failure Modes#

The job only researches#

Fix: write the prompt with a hard deliverable: publish one page, run build, push, verify.

The job writes content but never ships#

Fix: include commit/push/deploy verification in the prompt and give the job terminal/file tools plus the repo workdir.

The job sends to the wrong place#

Fix: use an explicit delivery target, especially for Telegram group topics.

The job silently stops after a few runs#

Fix: set repeat to forever or a very high repeat count for ongoing operations.

The script prints noise every day#

Fix: use no_agent only for deterministic watchdogs. For editorial work, use an LLM-driven cron job because the task requires judgment and writing.

Best Uses for Hermes Cron#

Hermes cron is strongest when the work has a clear recurrence and a clear deliverable:

• Daily SEO publishing.
• Weekly competitor intelligence.
• Morning engineering triage.
• Scheduled customer-support summaries.
• Market or GitHub issue monitors.
• Personal assistant routines: calendar, email, travel, reminders, errands. For hosted operations, FlyHermes is the commercial path when you do not want to maintain the runtime yourself.

The point is not to schedule more notifications. The point is to schedule completed work. If a scheduled job calls MCP tools, read the MCP security risks guide first and keep unattended write access narrowly scoped.

Cron job examples by outcome#

A useful Hermes cron job starts from the outcome, not from the schedule. Pick the shape that matches the work:

• Daily report: ask Hermes to gather sources, summarize what changed, and send the result to Telegram or Discord. Success means the report was delivered to the exact chat or channel.
• Publishing job: ask Hermes to update a page, run tests, deploy, and verify the live URL. Pair this with the Hermes Web UI dashboard so the active profile, tools, cron state, and gateway delivery are visible.
• Quiet monitor: use a script-only job when the script can decide whether anything changed. Success means silence when nothing changed and a concise alert only when a threshold is crossed.
• Gateway health check: schedule a small check that verifies the long-running service and sends one proof message. If delivery fails, use the gateway troubleshooting guide before rotating tokens.
• Repository maintenance: schedule a weekly dependency, documentation, or internal-link pass from the correct project workdir, then require a clean git diff, passing tests, and a pushed commit.

The important distinction is that Hermes cron is not a reminder app. A reminder tells you to do the work. A Hermes cron job should do the work, verify it, and report the proof.

Copy-paste safe cron templates#

Use these as starting prompts inside hermes cron create, then edit the project path, delivery target, and success condition.

LLM-driven publishing or research job#

Run from /path/to/project. Inspect current evidence before writing. Ship one concrete improvement, run the relevant tests, verify the live result, and report the URL plus command output. If the result is not live and verified, do not call the job successful.

Script-only silent watcher#

Run the configured script. Print nothing when there is no meaningful change. Print one concise alert only when the threshold is crossed. Never spend model calls for deterministic checks.

Gateway delivery smoke test#

Check the active Hermes profile, gateway status, provider health, and the exact Telegram/Discord delivery target. Send a short proof message only after the checks pass. If delivery fails, include the failing layer and the next command to run.

These templates deliberately include verification language because scheduled jobs run when you are not watching them. Without a success condition, a cron can produce a plausible report while failing to deploy, deliver, or alert.

FAQ#

Can Hermes cron jobs use tools? Yes. LLM-driven cron jobs can use the enabled toolsets you configure, such as web, terminal, file, browser, or GitHub-related tools.

Can a cron job run without the LLM? Yes. Use script-only no_agent mode when stdout is the final message and no reasoning is needed.

Should daily content jobs use no_agent? Usually no. Publishing content requires topic selection, judgment, writing, tests, and deployment verification. That should be an agent job.

What schedule format should I use for daily jobs? Use 0 9 * * * for 9am daily, or natural language like every day at 9am when creating from chat.

What counts as success? For publishing: a committed change, a passing build, a pushed branch or deploy, and a live URL. Anything less is an incomplete automation.

Scheduled jobs need clean memory boundaries#

Cron jobs are only reliable when the job runs in the intended profile with the intended memory, skills, and provider config. Recent context and memory support threads show why a daily job should not depend on a messy interactive session. For recurring work, keep durable facts in memory, procedures in skills, and debug recall failures with the memory/context troubleshooting checklist.

Provider reliability is part of this workflow too. If setup fails because credits, API keys, rate limits, or model switching are unclear, use the Hermes Agent model provider costs guide to choose a primary model lane, a cheaper routine-work lane, and a local or hosted fallback before blaming the rest of the stack.

If cron is part of an always-on assistant, start from the Hermes 24/7 AI agent setup guide so the runtime, provider credits, gateway delivery, dashboard checks, and script-only jobs are designed before alerts depend on them.

The safe cron pattern: scheduled work, not scheduled hope#

A good Hermes cron job has a success condition the agent can prove. “Check the website” is vague. “Open the production URL, confirm the title and CTA exist, run the mobile no-overflow check, then send the live URL” is a real scheduled-work contract.

Use this pattern before connecting a cron job to Telegram delivery, Discord delivery, GitHub, or a publishing repo:

1. Write a self-contained prompt. Cron runs do not inherit the full original chat. Include the repo path, data sources, success condition, and delivery target.
2. Pick the right mode. Use LLM-driven cron for judgment-heavy tasks; use no_agent=true script-only jobs for deterministic monitors that should stay silent unless a threshold trips.
3. Pin the environment. Set the profile, working directory, toolsets, skills, model/provider, and channel delivery explicitly.
4. Verify the output path. For reports, check the target chat/topic. For site changes, run tests, build, push, and live-rendered QA. For alerts, confirm the quiet path prints nothing.
5. Watch costs and retries. Scheduled agents can call models, tools, browser sessions, and auxiliary models. Pair cron with the provider fallback guide and the dashboard/Web UI so failures are visible.

If the job must stay online while your laptop sleeps, pair it with the 24/7 Hermes setup guide, VPS deployment guide, or the managed FlyHermes path.

Cron delivery depends on gateway health#

A scheduled job can finish successfully and still fail the user-visible outcome if delivery is pointed at a stale Telegram topic, Discord channel, or stopped gateway. For important recurring jobs, pin the delivery target and pair cron QA with the gateway troubleshooting checklist, especially after provider changes, Docker rebuilds, or service restarts.

Dashboard checks for scheduled jobs#

The dashboard is useful for cron jobs, but it should not be the success condition. Use the Hermes Agent Dashboard/Web UI to confirm that the right profile, provider, skills, tools, memory, gateway, and delivery target are active. Then verify the actual artifact: a sent Telegram message, a Discord post, a committed file, a live URL, or a quiet monitor that emitted nothing because no threshold was crossed.

A safe scheduled-work checklist:

1. Run hermes cron list and confirm the schedule, timezone, profile, workdir, toolsets, and delivery target.
2. Open hermes dashboard --no-open --port 9120 privately on a server only when you need a visual check.
3. Require the prompt to state the deliverable, not just “send a report.” For publishing jobs, the success condition is a live page plus QA, not a draft.
4. Use script-only no_agent=true cron for deterministic monitors and LLM-driven cron for editorial, research, or judgment-heavy work.
5. After a provider 429/402/rate-limit incident, either reduce the job or move deterministic parts into a script so the scheduler does not silently fail every day.

Community evidence backs this exact split: the May 2026 Discord scrape grouped 146 cron/goals/Kanban threads beside 122 messaging-platform threads and 87 dashboard/UI threads. People do not only ask “can Hermes schedule?” They ask whether the scheduled run actually reached Telegram, Discord, a file, or a production URL without breaking the setup.