Hermes Gateway Keeps Restarting: 3 Measured Causes

A Hermes Agent gateway that keeps restarting almost always has one of three measurable causes: memory that grows until a restart hides it, a dashboard build that exhausts small servers, or a disk that quietly fills up. All three have been documented by users in the Hermes Agent issue tracker during 2026, with numbers attached. This page walks through each one, how to confirm which is yours, and the exact commands to run.

In plain terms: your agent goes quiet, you check the server, and the gateway process has restarted on its own. The message history survives. The uptime counter went back to zero. Here is what the evidence says is happening.

First, confirm what is actually restarting

The gateway is the always-on process that connects your Hermes Agent to Telegram, WhatsApp and the other channels. The official FAQ at hermes-agent.nousresearch.com documents the commands:

hermes gateway status
cat ~/.hermes/logs/gateway.log | tail -50

The first line tells you whether the gateway is running right now. The second shows the last 50 lines of its log, which is where a restart leaves its footprints. If the process runs under systemd, one more command shows whether the operating system killed it:

journalctl -u your-hermes-unit --no-pager | grep -i "oom\|killed" | tail -20

The phrase to look for is oom-kill. It means the server ran out of memory and the operating system chose your gateway as the process to sacrifice. That single word separates cause one and cause two below from ordinary crashes.

Cause 1: gateway memory grows until a restart hides it

On July 5, 2026, a user running Hermes Agent v0.18.0 on a Debian 13 server reported in issue 58817 that the gateway process grew from roughly 300 MB at a fresh start to between 1.4 and 1.6 GB after about 20 hours. That is a five-fold increase on a lightly loaded machine with a single Telegram channel and one daily scheduled job.

The detail that matters for this page: the user's daily scheduled restart was masking the growth. The gateway looked like it was recycling routinely. It was actually leaking, and the restart was the only thing keeping it inside the server's memory. The report links the same pattern to an earlier thread, issue 48287.

What this means for you: if your gateway restarts on a rhythm, once a day or once every few hours, measure its memory before trusting that rhythm. Run this twice, a few hours apart, and compare:

ps -o rss=,etime=,cmd= -p $(pgrep -f "hermes" | head -5)

If the number climbs steadily between checks, you have the growth pattern. Two workable responses, in order of effort: give the machine enough headroom that the growth never reaches the ceiling between restarts, or schedule the restart yourself at a quiet hour so it happens on your terms. A restart you chose at 05:00 is a very different experience from one the kernel chose in the middle of a task.

Cause 2: the dashboard build that eats small servers

On April 24, 2026, issue 14898 documented a different killer with the same symptom. The hermes dashboard command rebuilt the entire web interface, a npm install plus TypeScript plus Vite build, on every single startup. On a VPS with 960 MB of RAM the build consumed everything, and systemd logged the result:

hermes-dashboard.service: Failed with result 'oom-kill'
Consumed 43.891s CPU time, 387.9M memory peak

What this means for you: a 1 GB server is below the practical floor for running the Hermes dashboard alongside the gateway. The build alone peaked near 400 MB in the report above, before the gateway, the agent and the operating system claimed their share. If your restarts line up with dashboard starts and your server has 1 GB or less, the memory is the whole story. Move to a 2 GB or larger machine, or leave the dashboard off on that box and manage the agent from the command line.

Cause 3: the disk fills while nobody watches

A gateway also restarts badly when its disk runs out, and Hermes has a documented way of getting there. In issue 58172, opened July 4, 2026 and still open at the time of writing, a user running a long-term gateway on a 29 GB cloud server found that every hermes update added new git objects without cleaning old ones. After several months the hidden .git folder alone had grown to 884 MB. Running git gc --aggressive inside the install directory brought it down to 592 MB.

Check your own numbers with two commands:

df -h /
du -sh ~/.hermes 2>/dev/null; du -sh $(which hermes | xargs dirname)/.. 2>/dev/null

What this means for you: a server that runs for months accumulates weight that a laptop never would, because the laptop gets wiped and reinstalled. Logs, update leftovers and session files all grow in one direction. A monthly look at df -h costs ten seconds and prevents the ugliest failure mode, which is a database or log write failing mid-message.

The 15-minute diagnosis, in order

Run these in sequence and stop at the first one that shows a problem. The order goes from most common to least common, based on the issues above.

1. Is it running now? hermes gateway status
2. What do the last 50 log lines say? cat ~/.hermes/logs/gateway.log | tail -50
3. Did the system kill it? journalctl output containing oom-kill means too little RAM for what the box is asked to do.
4. Is memory climbing? Two ps -o rss= readings a few hours apart. Steady growth points to issue 58817's pattern.
5. Is the disk near full? df -h / above 90 percent explains almost any strange failure.
6. Still unclear? Restart once, deliberately, with hermes gateway restart, and watch the log live while sending the agent one message.

A Hermes Agent needs what any always-on service needs: enough RAM that growth has somewhere to go, enough disk that months of uptime have somewhere to land, and someone who reads the logs before the restart becomes a habit. That is true whether the machine is under your desk or in a datacenter. Our managed Hermes Agent hosting sizes the server for the gateway plus dashboard from day one and watches memory and disk for you, with a 7-day free trial and no card required.

Sources: Hermes Agent issues 58817, 14898, 58172, and the official Hermes Agent FAQ. All figures are the reporters' own measurements as published on the dates given.