All flows
GuidesIntermediate

Nobody Talks About the Hermes Dashboard. I Open It Every Day. Here's Why.

Discover the power of the Hermes dashboard as a daily operating surface. The community obsesses over SOUL.md and overnight loops, but the unglamorous browser tab at localhost:9119 is where you actually keep a 24/7 agent healthy — Sessions, MCP, Skills, Cron, Analytics, Logs, and System.

Tamsi Besson (@tamsi_besson) on XTamsi Besson8 min read22 Jun 2026

Scroll Hermes Twitter, Reddit, or the flows on this site. You'll find a lot of posts about SOUL.md, multi-agent setups, Telegram gateways, /goal, Polymarket trading bots, and the 9-hour overnight workflow.

You'll find far less about hermes dashboard as a daily operating surface. The official docs cover it well. Community write-ups rarely do.

I think that's a gap — and it's probably why a lot of people stall after the initial install honeymoon. They set up Hermes Desktop or run hermes chat once, configure everything in YAML, lose track of what their agent actually did, and wonder why Hermes feels like a fancy chat app instead of a system.

I use Hermes Desktop when I want to talk to the agent — that's my main chat surface, not a raw terminal. I use Telegram when I want Hermes to reach me. But I open the dashboard every single day because it's where I can see and operate the whole machine in one browser tab. And when I do want the CLI, I don't need a separate terminal: the dashboard Chat tab embeds the full TUI (hermes --tui) right in the browser.

This isn't a feature tour. It's the honest account of why the boring browser tab became the most important window in my Hermes setup.

The content gap (relative, not absolute)

Hermes has a lot of surfaces, and the community attention is uneven:

SurfaceCommunity attention
SOUL.md / personalityVery high
Telegram / gateway setupVery high
Cron / overnight automationHigh
Multi-agent / KanbanGrowing fast
Web dashboard as daily ops toolMuch lower

The dashboard doesn't photograph well. There's no dramatic before/after. No 170-line markdown file to share. No "my agent made $12 while I slept" headline.

It's a local admin UI at localhost:9119. It looks like settings pages and tables. So a lot of people skip it — and then wonder why their MCP server silently stopped working three days ago.

To be fair: Hermes Desktop shares the same backend and covers overlapping ground (Skills, Cron, Channels, Profiles). I use Desktop for chat and the browser dashboard for ops — they're complementary, not competing. The official docs have a full Web Dashboard page. What's missing is the practitioner angle — someone saying "I live here, here's my actual routine."

What the dashboard actually looks like

In current Hermes (v0.17), opening http://127.0.0.1:9119/ lands on Sessions — not chat by default. The left sidebar is the map of everything: Chat (the real TUI over PTY — slash commands, tool cards, approvals), Sessions, Files, Models, Logs, Cron, Skills, Plugins, MCP, Channels, Webhooks, Profiles, Config, Keys, System.

I mostly chat from Hermes Desktop, but the dashboard Chat tab is the same agent when I'm already in the browser configuring things.

At the bottom of that sidebar, a System strip shows gateway status, active sessions, and quick actions (restart gateway, update Hermes). That's my morning heartbeat check before I read a single session.

What changed when I stopped ignoring it

My old workflow: edit config.yaml, run hermes mcp add from memory, grep logs in the terminal, hope the gateway was still up.

My current workflow: open the dashboard first thing, read the sidebar System strip, skim Sessions, and I know immediately if something is wrong before I waste a chat turn.

That single habit changed everything. The dashboard isn't my primary chat window — Desktop is. It's where I operate Hermes.

My daily dashboard — what I actually open

Here's what a normal day looks like for me. Not aspirational. Not a setup guide. Just what I click.

Morning: Sessions + sidebar status (2 minutes)

I keep the dashboard backend running — Hermes Desktop does this automatically on my machine, or I run hermes dashboard in a long-lived tmux/systemd session. Then I just open the browser:

http://127.0.0.1:9119

First checks:

  • Sidebar → System: is the gateway running? How many active sessions?
  • Sessions page: message totals, per-source breakdown (CLI, cron, Telegram…), connected platforms

If a cron job ran at 3am and delivered garbage to Telegram, I don't find out from the message alone — I find out in Sessions. I search across message content (FTS5 in the dashboard UI), expand the cron session, read the tool calls, and see exactly where it went wrong.

The CLI can do related work too. I still prefer the dashboard here because I get search + full history + tool-call inspection in one visual flow.

When I add or fix an integration: MCP (5 minutes)

Every time I connect a new tool — GitHub, a database, an internal API — I use the MCP tab, not raw YAML editing.

Why? The Test button (lightning icon). It connects, lists the tools, and disconnects. I know the integration works before I start a chat session and wonder why the agent can't see my tools.

I've lost count of how many times I had a server in config.yaml that was enabled: false, or had a typo in the env var, or needed a gateway restart. The MCP tab shows all of it visually. Enable, test, restart gateway from Channels or System, done.

Per the official docs, MCP enable/disable takes effect on the next gateway restart — not instantly mid-session.

When the agent feels "off": Skills (3 minutes)

Before I blame the model, I open Skills:

  • Is the skill I expect actually enabled?
  • Are the right toolsets active?
  • Did something get archived? (The background curator moves long-unused agent-created skills to ~/.hermes/skills/.archive/ — check System → Skill curator or hermes curator list-archived, not just the enable toggle.)

A well-used Hermes instance accumulates dozens of skills. They're invisible in daily chat — you don't see which playbook the agent loaded. The Skills tab is where procedural memory becomes tangible. Toggle one off, start a fresh session, notice the difference.

When I want Hermes to work without me: Cron

I create and debug cron jobs in the Cron tab, not only the CLI.

Because I need to see:

  • Is the job paused or errored?
  • When did it last run?
  • What's the delivery target?

And when I'm testing, I hit Trigger now instead of waiting for the schedule.

When I'm curious about cost: Analytics

This tab has no hype around it whatsoever. I love it — when it's enabled.

Token usage per day. Per model. Estimated cost. Cache hit rate. After a heavy week, I open Analytics and see whether I should switch models, reduce cron frequency, or fix a runaway job.

Note: in v0.17, local token analytics can be hidden by default. If you see a "TOKEN ANALYTICS HIDDEN" message, set dashboard.show_token_analytics: true in Config (or config.yaml). The numbers are estimates — check your provider dashboard for authoritative billing.

When something breaks: Logs + System

Logs — filter by gateway/agent/errors, tail live, find the line.

System — host stats, gateway start/stop/restart, memory provider, credential pools, doctor, backup/restore, skill curator.

I reach for Hermes Desktop when I want to work with the agent. I reach for the dashboard when something is wrong — or when I need to change how the agent runs.

Why I think a lot of people skip it

Three reasons, in my experience:

1. It looks like admin UI, not magic.

SOUL.md posts spread because they're copy-paste identity files. Dashboard posts would be screenshots of tables. Less shareable. More useful.

2. People conflate chat with the whole product.

Hermes Desktop, the dashboard Chat tab, and hermes chat in a terminal all talk to the same agent. Easy to think you've "seen Hermes" after installing one of them — and never open Sessions, MCP, or Cron. The chat surfaces are real; they're just not the ops layer.

3. YAML + Desktop alone is good enough until it isn't.

A clean Desktop install works fine when you have one profile, a handful of skills, and no cron. It gets harder when you have multiple profiles, dozens of skills, several MCP servers, a gateway on Telegram, and cron jobs delivering to multiple platforms. That's infrastructure — and infrastructure benefits from a control panel.

The one concept that made it click

Hermes Desktop (or the dashboard Chat tab) is for conversations.

The dashboard is for the system that runs conversations.

Hermes persists memory, skills, sessions, cron, and messaging whether or not a chat window is open. The dashboard is where I see that state. Desktop and dashboard share the same config — I use each for what it's best at.

Once I internalized that, I stopped treating hermes dashboard as optional.

Desktop vs dashboard vs CLI — how I actually split it

What I'm doingWhere I go
Daily chat, file browser, native GUIHermes Desktop
Ops: sessions, MCP, cron, skills, logsDashboard (hermes dashboard or Desktop's backend)
Chat while already in the dashboardChat tab (embedded TUI — same as CLI, no extra terminal)
Scripting, piping, automationCLI in a real terminal
Hermes reaches me on my phoneGateway (Telegram, etc.)

Desktop is my agent UI. The dashboard is my control room.

The bottom line

The community posts a lot about personality files, messaging bots, and overnight loops — all valuable.

But day-to-day operations — the unglamorous work of keeping a 24/7 agent healthy — gets far less attention than SOUL.md threads. For me, the dashboard is where that work happens.

If you're past the "I installed Hermes and it chats" stage and want it to actually operate, open the dashboard. Start with Sessions and the sidebar System strip. Search Sessions when something breaks. Test MCP servers before you trust them.

It's not glamorous. It's the most powerful part of Hermes I've found.

This flow was shared by a community member. The Hermes Bible is an unofficial, community-built resource and is not affiliated with Nous Research.

Related flows