Skip to main content
HERMINA · YOUR PERSONAL HARNESSExplore
Docs/Tasks and schedules

Tasks and schedules

Hermina provides two automation mechanisms: a persistent queue for discrete work and Hermes cron jobs for time-based execution. Use the queue when another system submits work; use cron when time is the trigger.

Choose the right mechanism

NeedUseWhy
Run something at a specific time or intervalAgent cronThe schedule belongs to Hermes and follows the agent profile
Submit work from a script or integrationTask queuePersistent status, result, and failure state
Schedule work for the host Hermes profileHost cronRuns outside one named agent profile
Review automation output in the UICron + Inbox/FeedDesigned for operator visibility and delivery

Start with a manually triggered prompt. Schedule it only after the prompt, model, tools, and delivery destination work interactively.

Agent cron jobs

List jobs for one agent:

hermina agent-cron analyst list

Create a recurring job:

hermina agent-cron analyst create \
  "every 1h" \
  "Summarize new activity and highlight anything that needs attention" \
  --cron-name=hourly-summary \
  --deliver=local

Common lifecycle actions include list, create, remove, pause, resume, and run. Use the job ID printed by the list command for lifecycle actions:

hermina agent-cron analyst run --job-id=<job-id>
hermina agent-cron analyst pause --job-id=<job-id>
hermina agent-cron analyst resume --job-id=<job-id>
hermina agent-cron analyst remove --job-id=<job-id>

The dashboard and Android app expose the same per-agent schedule management with execution history and notification state.

Host cron jobs

Host cron uses the host Hermes profile rather than an agent profile:

hermina host-cron list
hermina host-cron create \
  "every day at 09:00" \
  "Review the server status and summarize failures" \
  --cron-name=daily-health \
  --deliver=local

Host jobs have the permissions and context of the host profile. Use them for infrastructure-level work, not as a substitute for an isolated agent.

Persistent task queue

Each container agent has a SQLite queue, an internal Queue API, and a worker. The data remains in agents/<name>/queue.db across container restarts.

Check health and recent tasks:

hermina queue health analyst
hermina queue list analyst
hermina queue status analyst

Enqueue a goal:

hermina queue enqueue analyst goal \
  '{"goal":"Review the latest workspace report and produce three next actions"}'

Enqueue a command:

hermina queue enqueue analyst command \
  '{"command":"ls -la /root/.hermes"}'

Supported queue types include noop, command, webhook, send_message, and goal. Payloads are JSON. If a plain string is supplied, the CLI wraps it as a text field.

Inspect or cancel a task:

hermina queue status analyst <task-id>
hermina queue cancel analyst <task-id>
hermina queue logs analyst --lines=50

Only pending tasks can be cancelled reliably; a processing task may already be executing.

Delivery and operator visibility

Cron output can feed the dashboard Inbox, activity Feed, or a configured channel depending on its delivery setting. Check both job execution status and final delivery status—a successful model run can still fail to reach a channel.

Use clear names such as hourly-summary, daily-health, and weekly-report. Include the expected output and failure behavior in the prompt.

Reliable automation checklist

Before enabling a recurring job:

  1. Run the prompt manually in a clean chat.
  2. Confirm every required tool and credential.
  3. Use an explicit timezone and verify the server timezone.
  4. Keep the prompt idempotent when retries are possible.
  5. Choose a delivery destination and test it.
  6. Define what the agent should do when source data is missing.
  7. Review the first several executions in Inbox or history.

Troubleshooting automation

SymptomCheck
Job never startsSchedule syntax, pause state, server time, agent runtime
Job starts but failsAgent logs, provider credentials, tool permissions
Queue remains pendinghermina queue health, worker logs, running container
Result exists but no notificationDelivery target and channel connection
Duplicate side effectsIdempotency, retry behavior, overlapping schedules