"Messaging gateway stopped" means the Hermes process that connects your agent to Telegram, Discord, Slack and the rest is not running, even when the platform reads Saved. Run hermes gateway status, read ~/.hermes/logs/gateway.log, and fix what the log names: usually a second process on the same bot token, a rejected token, or a service that was never installed. Then restart with hermes gateway restart.
Everything below is checked against Hermes Agent v0.21.5 (tag v2026.9.24), the latest release as of 3 October 2026, and its official docs.
What is the Hermes messaging gateway?
The messaging docs describe it as a single background process that connects to all your configured platforms, handles sessions, runs cron jobs and delivers voice messages. The agent itself does not need it, so the classic symptom is a bot that ignores you while hermes in a terminal answers instantly.
The same docs say Saved means credentials are stored, "not that the messaging gateway is running or the platform is connected." Hermes Desktop adds confusion: an open issue (#120641) reports the status bar reading "Gateway ready" (the backend connection) while the Telegram page says "Messaging gateway stopped". Trust the CLI over the badge.
How do I check whether the gateway is running?
Start with status, then the logs (all from the CLI reference):
hermes gateway status # the default service
hermes gateway list # every profile, with PIDs
hermes logs gateway -n 100 # last 100 lines of gateway.log
hermes logs errors --since 1h # errors.log, last hour
# Linux service logs
journalctl --user -u hermes-gateway -n 200 # user service
sudo journalctl -u hermes-gateway -n 200 # system service (--system install)
# macOS (launchd)
tail -f ~/.hermes/logs/gateway.logTwo status lines are worth knowing. ⚠ Gateway exited degraded: event loop stopped dispatching … means the built-in watchdog found the process frozen and exited with code 75 so the service manager restarts it. ⚠ Gateway heartbeat stale means the process is alive but its housekeeping stopped; restart it.
Why did the Hermes gateway stop?
| What you see | Likely cause | Fix |
|---|---|---|
terminated by other getUpdates request | Another process polls the same Telegram token | Stop the other process, then hermes gateway restart |
Telegram bot token already in use | A second Hermes gateway on this machine holds the token | Stop that gateway first |
Gateway hit a non-retryable startup conflict or No connected messaging platforms remain | The only platform failed for good, often a revoked token | Fix the token, restart |
No adapter available for telegram | That platform's dependencies are missing from the Hermes install | Install them for your install method, then restart |
| Nothing at all; the process is just gone | It ran in a terminal with no supervisor | hermes gateway install |
| Stops at logout, missing after reboot | Linux user service without linger | sudo loginctl enable-linger $USER |
Two processes are using one bot token
Telegram allows one poller per bot token. When a second appears, Hermes logs terminated by other getUpdates request, retries five times (Telegram polling conflict (1/5) and so on), then gives up with this message from the adapter source:
Telegram polling could not recover after 5 retries (200s total wait). The previous gateway session is still held open on Telegram's servers, or another process is using the same bot token. To recover: ensure no other Hermes or OpenClaw instance is running with this token, then restart the gateway with 'hermes gateway restart'.
The usual culprits: an old VPS still running, a Docker container plus a host service, both a user and a system unit installed (the docs warn against this), or an OpenClaw agent on the same token. Running both runtimes? Give each its own bot; our OpenClaw vs Hermes comparison covers how they differ.
On one machine, Hermes catches the clash earlier with Telegram bot token already in use, naming the PID or profile that holds it. According to the gateway internals doc, a clash at startup with nothing else connected makes the gateway exit with code 78, and the generated systemd unit uses RestartPreventExitStatus=78, so systemd deliberately stops retrying. Status 78 in systemctl --user status hermes-gateway means the service is waiting for you to fix the config.
The token is wrong or was revoked
Hermes treats an invalid or forbidden Telegram token as a permanent failure. If Telegram is your only platform, the gateway gives up: at startup it logs Gateway hit a non-retryable startup conflict and exits with the same parked code 78 described above; mid-run it logs No connected messaging platforms remain. Shutting down gateway cleanly. Check the token directly against the Bot API:
curl -s "https://api.telegram.org/bot<YOUR_TOKEN>/getMe""ok":true means the token is valid. Otherwise, the Telegram guide says to generate a new one in BotFather, update ~/.hermes/.env, and restart.
Nothing was supervising the process
Bare hermes gateway runs in the foreground. Close the terminal or drop the SSH session and the bot dies with it, silently. Install it as a service instead (see below). On Windows, the Scheduled Task's RestartOnFailure covers only the launcher, so a gateway killed later stays down until hermes gateway start. On WSL2, the FAQ recommends hermes gateway run inside tmux because WSL's systemd support is unreliable.
The user service stops at logout or never starts at boot
hermes gateway install on Linux creates a systemd user unit. Without linger, it stops when your last session ends and does not start at boot, which on a headless server looks like a random outage. The fix is sudo loginctl enable-linger $USER; our post on systemd user services being unavailable explains the mechanics, which apply to Hermes the same way.
It stopped right after an update
hermes update restarts running gateways when it finishes. The exception, per the messaging docs: with a system service and no passwordless sudo, it skips the restart and prints the manual sudo systemctl restart hermes-gateway command, which is easy to miss. Older Desktop builds did not restart the messaging gateway after an update either (#38134; the closing note says the fix shipped in v2026.7.1). After any update, run hermes doctor, hermes config check and hermes gateway status; status warns when the installed unit is outdated, and one hermes gateway restart picks up the new one.
How do I restart the Hermes gateway properly?
Use hermes gateway restart. It sends SIGUSR1, so the gateway refuses new turns, waits up to agent.restart_after_turn_timeout (default 1800 seconds) for in-flight turns, exits, and the CLI waits for the replacement. A raw systemctl restart hermes-gateway stops the process on systemd's schedule instead. Both are clean, but only the first lets a long task finish.
Do not add an ExecStopPost kill drop-in to "make sure" it stops. The docs warn it kills the fresh instance on every restart and causes an infinite restart loop.
How do I make it survive reboots?
On Linux, pick one of these, not both:
# Option A: user service plus linger (recommended for headless VMs)
hermes gateway install
sudo loginctl enable-linger $USER
# Option B: boot-time system service that still runs as your user
sudo hermes gateway install --system
sudo hermes gateway start --systemOption A lets hermes update restart the gateway without root. For whole-process freezes, opt into a systemd watchdog in ~/.hermes/config.yaml, then regenerate the unit:
gateway:
systemd_watchdog_seconds: 120hermes gateway install --forceOn macOS, hermes gateway install writes a launchd agent that snapshots your PATH, so re-run it after installing Node or ffmpeg.
Is the gateway stopped, or running but not receiving?
If hermes gateway status says running and the bot is still silent, something inside the process is refusing your messages:
- No allowlist. The startup log says
No user allowlists configured. All unauthorized users will be denied.Telegram fails closed whenTELEGRAM_ALLOWED_USERSis empty (since v0.15.0), and Discord logsNo Discord access policy configured; inbound Discord messages will be denied by default.See the security docs. - One platform parked, the rest fine. If one platform fails permanently at startup while others connect, the gateway stays up and logs
configured platform(s) failed to start and are parked. Fix the reported error, thenhermes gateway restart. - A paused adapter. Each platform has a circuit breaker. After repeated failures it pauses that adapter and does not resume on its own. Send
/platform listfrom another connected chat or the CLI;paused-by-breakermeans run/platform resume telegramonce the platform is healthy. - A model that fails every turn.
Model X has a context window of N tokens, which is below the minimum 64,000 required by Hermes Agent.is raised when an agent is built for a conversation, not when the gateway starts, so look inerrors.log, not at the service state.
What this looks like when someone else runs the gateway
On Qoren's Hermes hosting, each agent gets its own gateway as a system service (hermes-gateway-<slug>) with Restart=always, so there is no linger to forget. It also sets OOMPolicy=continue: when the kernel kills a hungry tool subprocess, only that subprocess dies, and the conversation on Telegram carries on. Each agent signs in with its own bot, so agents never clash over a token, and the console shows every channel as Connected or Needs attention with the reason underneath; the agent not responding checklist walks through it.
One caveat: Qoren pins a tested Hermes release and upgrades it deliberately rather than tracking the newest tag, so some messages above may read differently on a Qoren agent.