Hermes cron is where the tool starts feeling less like a smart terminal companion and more like a dependable little operator. Once you have the provider and basic CLI setup working, scheduled jobs are the next step that turns one-off prompts into reports, monitors, and repeatable background work.

In this guide, I'll show you the safest first cron workflow: verify the scheduler, create one local job, test it without waiting all day, and then tighten the prompt so the job still makes sense when no human is around to explain what you meant.

If Hermes is not installed yet, start with Install Hermes Agent on Linux and Complete Your First Setup. If you still need to switch providers or point Hermes at a different model, Configure Models and Providers in Hermes Agent is the right companion before you automate anything.

What Hermes scheduled jobs are good at

Hermes scheduled jobs work well for tasks like:

• morning reports
• recurring audits
• change monitoring
• scheduled research summaries
• project-specific maintenance checks
• skill-backed workflows that need to run on a timetable

Each cron run starts in a fresh agent session. That is powerful, but it also means the job does not remember your current chat. If the prompt is vague, the result will be vague too.

Before you create the first job

Make sure these basics are already true:

• the hermes command works in your shell
• your model/provider setup is stable enough for unattended runs
• the gateway or scheduler process is actually running
• you know where you want the output to go: local files, the origin chat, or a platform such as Telegram

On the system I'm using here, hermes cron status reports the scheduler as active and ready to fire jobs automatically.

Step 1: Check that the scheduler is running

Start by checking the scheduler state.

hermes cron status

If cron is healthy, you should see output that confirms the gateway is running and gives you the next scheduled fire time.

✓ Gateway is running — cron jobs will fire automatically

If the scheduler is not running yet, you can start Hermes in the foreground for testing:

hermes gateway

If you want Hermes cron to keep running on a server, install the gateway service instead.

hermes gateway install

For a Linux machine where you want boot-time system service behavior, Hermes also supports the system-wide install path:

sudo hermes gateway install --system

Step 2: Review existing jobs before adding another one

List the jobs Hermes already knows about.

hermes cron list

This is the quickest way to avoid duplicate schedules, check whether a job is paused, and spot the job ID or name you will need later for edits and test runs.

Hermes stores the schedule definitions in ~/.hermes/cron/jobs.json, and local-output jobs write their results under ~/.hermes/cron/output/.

Step 3: Create a first job with local delivery

For a first test, I recommend local delivery. It is quieter, easier to inspect, and better for debugging than sending every early experiment straight to Telegram or Discord.

Create a weekday morning job like this:

hermes cron create "0 8   1-5" "Check disk usage, memory pressure, and failed services. Write a short sysadmin summary with the most important findings only." --name "Morning server check" --deliver local

That command gives you four useful habits right away:

• a normal cron expression for a predictable schedule
• a human-friendly job name
• a self-contained prompt
• local output instead of chat spam while you test

If you prefer natural-language schedules, Hermes accepts those too.

hermes cron create "every 2h" "Summarize anything new in the monitored feeds and respond with only [SILENT] if nothing changed." --name "Feed summary" --deliver local

Step 4: Test the job now instead of waiting for the clock

Once the job exists, trigger it for the next scheduler tick.

hermes cron run "Morning server check"

This is a queue request, not an instant inline run. Hermes marks the job to fire on the next scheduler tick, so give it a moment and then check the job list again.

hermes cron list

For one-off debugging on a machine where the gateway is not already running, you can also manually process due jobs once.

hermes cron tick

After a local-delivery run, inspect the saved output under:

~/.hermes/cron/output/<job_id>/

That folder is one of the easiest ways to confirm whether your prompt shape is actually producing the kind of report you wanted.

Step 5: Write prompts like nobody will be there to clarify them

This is the part that makes or breaks Hermes cron jobs.

A weak prompt looks like this:

• check the server and let me know if anything is weird

A better prompt does three things:

• says exactly what to check
• says what format to return
• says what to do in the no-change case

For example:

Check disk usage, memory pressure, and failed systemd services. Return a short report with sections for Disk, Memory, and Services. If everything looks normal, respond with only [SILENT].

That one extra minute of specificity usually saves a lot of cleanup later.

Step 6: Attach skills when they really add value

Cron jobs can load one or more skills before the prompt runs. This is useful when the repeated task already maps cleanly to a reusable workflow.

Here is a simple example:

hermes cron create "0 9   *" "Check the configured feeds and summarize anything new in a short brief." --skill blogwatcher --name "Morning feeds" --deliver local

You can also attach multiple skills in order.

hermes cron create "every 6h" "Use both installed skills and combine the results into one short operational brief." --skill blogwatcher --skill maps --name "Local brief" --deliver local

The order matters. Hermes loads the attached skills in the order you pass them.

Step 7: Use --workdir for repo-aware jobs

If a job needs to operate inside a real project, set an absolute working directory.

hermes cron create "every 1d at 09:00" "Audit open PRs, summarize CI health, and post the result." --workdir /home/you/projects/acme --name "PR audit" --deliver local

With --workdir set, Hermes runs the job from that directory and also loads project context files such as AGENTS.md, CLAUDE.md, and .cursorrules when they exist.

A couple of details matter here:

• the path must be absolute
• the directory must already exist
• workdir jobs run sequentially on a scheduler tick, which avoids one project job stomping on another job's working directory

If a cron task is supposed to behave like a repo-aware assistant rather than a generic global bot, --workdir is the flag that usually makes the difference.

Step 8: Pick the right delivery target

Hermes supports several delivery styles, but the practical beginner choices are these:

• origin — send the result back to the chat where the job was created
• local — save output under ~/.hermes/cron/output/
• telegram — send to your Telegram home channel
• telegram:<chat_id> — send to a specific Telegram chat
• discord or slack — send to the configured home channel for that platform

For example, this sends a daily summary to Telegram:

hermes cron create "0 9   *" "Summarize overnight alerts in five bullet points. If there is nothing meaningful, respond with only [SILENT]." --name "Daily alert digest" --deliver telegram

You do not need to call send_message inside the cron prompt. Hermes automatically delivers the final response based on the --deliver target.

Step 9: Use [SILENT] on purpose

[SILENT] is the difference between a useful monitoring job and a very enthusiastic nuisance.

When you want alerts only on changes or real findings, tell Hermes exactly that in the prompt. A good pattern is:

If nothing changed or there is nothing actionable, respond with only [SILENT].

Do not ask Hermes to wrap that marker inside a longer sentence. If the quiet marker appears in the final response, delivery is suppressed.

Common mistakes that trip people up

Expecting /run behavior from hermes cron run

hermes cron run <job_id_or_name> schedules the job for the next gateway tick. It does not run inline in your current shell.

Forgetting that each run starts fresh

A cron job does not remember the chat where you refined the prompt yesterday. Treat the job prompt like a tiny runbook, not a shorthand note.

Blaming the prompt when the gateway is not running

If cron never fires automatically, check the scheduler first.

hermes cron status

Sending noisy test jobs straight to messaging platforms

Start with --deliver local, inspect the output, and only then switch to Telegram, Discord, or another platform.

Using a relative workdir path

Hermes expects an absolute project path for --workdir. If the directory is missing or relative, the job creation or update is rejected.

Trying to create cron jobs from inside another cron job

Hermes blocks recursive cron management inside cron-run sessions. That guard exists for a good reason, and it keeps accidental scheduling loops from getting weird fast.

Files worth knowing when you troubleshoot

These are the first paths I check when a scheduled job is misbehaving:

• ~/.hermes/cron/jobs.json
• ~/.hermes/cron/output/
• ~/.hermes/logs/agent.log
• ~/.hermes/cron/.tick.lock

If a local-output job ran, the output directory usually tells you more quickly than guesswork will.

Where to go next

Once your first job is working, the next upgrades are usually obvious:

• use Configure Models and Providers in Hermes Agent if you need a more reliable provider or a different default model
• keep Install Hermes Agent on Linux and Complete Your First Setup nearby for rebuilds or clean-room setups
• pair cron with local-model workflows after you have a stable runtime in place, especially if you already use Ollama or Open WebUI elsewhere in your stack

A well-written Hermes cron job should feel boring in the best way. It wakes up, does the thing, stays quiet when nothing matters, and leaves you a useful result when it does.