Operate Gateway Platforms Without a Full Restart

A multi-platform Hermes gateway should not require a full restart for every channel problem. The /platform command exposes adapter status and control so an operator can inspect, pause, or resume one integration while leaving healthy platforms online.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/#operating-a-multi-platform-gateway

Isolate the fault first

Start with gateway status and the affected platform’s recent logs. Determine whether the failure is authorization, credentials, network transport, provider throttling, or agent execution. Use /platform from a connected surface to inspect individual adapters. Pause a failing adapter when retries are noisy or harmful, then repair and resume it without disturbing unrelated channels.

Hermes also uses an automatic circuit breaker for repeatedly failing adapters. A paused state is evidence to investigate, not an instruction to restart blindly. Check why the platform paused and whether credentials, permissions, or upstream service health changed.

Operations checklist

Confirm the gateway service itself is healthy.
Inspect the affected adapter independently.
Correlate logs with a timestamp and platform identity.
Pause only the failing adapter when possible.
Repair authentication, permissions, or network reachability.
Resume and send a harmless test message.
Verify inbound authorization and outbound delivery separately.
Use a full restart only when shared configuration or process state requires it.

Restart-interrupted sessions

If the gateway stops during a tool call or generation, Hermes marks affected sessions as restart-interrupted. On startup it can schedule recovery and notify the home channel. Treat that notification as a continuity aid, not proof the external action is safe to repeat. Before resuming, inspect whether the interrupted tool already produced a side effect.

Common pitfalls

Restarting every platform to fix one expired token.
Repeatedly resuming an adapter without reading its error.
Treating inbound success as proof outbound delivery works.
Replaying a side-effecting step after an ambiguous interruption.
Leaving detailed progress acknowledgments enabled in noisy public channels.
Forgetting that some configuration changes genuinely require a process restart.

Verification steps

List platform status and capture the affected adapter state.
Pause it and confirm healthy platforms continue responding.
Apply the narrow repair.
Resume and verify one inbound and one outbound message.
Inspect the logs for renewed circuit-breaker failures.
If a restart was required, review interrupted sessions before allowing automatic continuation.