hermesd

What hermesd does

Running Hermes seriously, a gateway handling Telegram, Discord, Slack and WhatsApp at once, cron jobs firing on schedule, several CLI sessions spawning sub-agents, means the operational picture is scattered across hermes status, hermes sessions list, hermes cron list and several log files. hermesd replaces that by reading ~/.hermes/ directly and rendering 13 dashboard panels covering gateway and platform health, session and token usage, cron and delivery queues, integrations and provider cooldowns, in one terminal command.

It makes zero writes to agent state and needs no API keys, with gateway responsiveness checks limited to a bounded local connection to the agent's own loop-tick witness. The latest release adds daily token history, per-job cron usage trends, broader redaction of sensitive data, bounded reads and a last-good recovery path so malformed or temporarily unreadable data does not break the dashboard.

Key features

• 13 dashboard panels covering gateway, sessions, tokens, cron, skills and logs
• Zero writes to Hermes state and no external API calls, fully read-only
• Daily token-usage history and per-job cron cost trends
• Broader data redaction and a last-good recovery path for malformed state
• Export of full detail snapshots from any panel view

When to use it

• Checking at a glance whether a busy Hermes gateway and all its platforms are healthy
• Spotting which cron jobs failed recently without tailing multiple log files
• Tracking daily token usage and estimated cost trends across sessions

Who it is for: Hermes Agent operators running a busy, multi-platform gateway who need one dashboard instead of several CLI commands and log files.

How it fits with Hermes Agent

hermesd is a dedicated, independently installed monitoring layer for Hermes Agent, reading its state directory without modifying it.

Note: Some dashboard panels depend on records that only newer Hermes Agent versions produce; older Hermes schemas fall back to a supported but reduced view.

FAQ