Hermes Incident Commander skill
A Hermes Agent skill and a standalone Linux watchdog that detects failures, diagnoses causes and restarts allow-listed services.
- 75 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- The watchdog can restart listed services and delete old logs, and a mistake in the list causes downtime.
- Demo and training environments give the model a full terminal, and host metrics go to an external API.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/hermes-incident-commanderDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- The watchdog can restart listed services and delete old logs, and a mistake in the list causes downtime.
- Demo and training environments give the model a full terminal, and host metrics go to an external API.
This is third-party code. Review the repository files before installing.
What it does
Hermes Incident Commander runs an incident through a loop: detect, triage, diagnose, remediate, verify, document and learn. The incident-commander skill goes into the Hermes Agent skills directory and fires on talk of a downed server, memory pressure, a full disk or a firing alert. Diagnosis relies on ordinary Linux, Docker and Kubernetes commands. A separate `monitor/watchdog.py` watchdog runs on any Linux host without Hermes and needs only an Anthropic key. It collects metrics itself, sends the model numbers only and notifies Discord, Slack, Teams, PagerDuty or a generic webhook. Past incidents are searchable in a local SQLite database and metrics are exposed in Prometheus format.
Who it is for. Administrators and SRE engineers of small Linux servers who want an on-call helper with limits on its actions.
Good fit when
- A service fails at night and a root cause analysis is needed by morning.
- CPU and memory metrics are watched with alerts sent to Slack or Teams.
- Allow-listed services are restarted automatically from a predefined list.
- You check whether a similar incident happened before, using the local log.
Not a fit when
- You want a watchdog for a critical production system without reviewing the allow-list of actions.
- Anthropic key access is blocked and a model cannot be attached to the watchdog.
- The host does not run Linux.
Example request
Check server health, find the cause of high CPU load and propose actions without restarting anything until I say so.Limitations
Demo mode and the reinforcement learning environment give the model unrestricted terminal access, so run them only in a disposable sandbox. The watchdog gives the model no shell, and actions are limited to restarting listed services and deleting old logs in listed folders. Auto-remediation is off by default, but a mistake in the list, such as a critical service among restart entries, will cause its restart. The Anthropic API is unavailable from Russia, and the watchdog needs a key. The author recommends reading SAFETY.md before running anything.
How to disable. Stop the watchdog and remove the service with `./scripts/install-watchdog.sh --uninstall --yes`. Remove the skill folder from `~/.hermes/skills/` and clean incident history separately.
FAQ
Is Hermes Agent required?
No. The `monitor/watchdog.py` watchdog runs on its own and needs only an Anthropic key. Hermes is needed for the skill and in-agent scheduled checks.
What does the watchdog do on its own?
By default it only observes, diagnoses, writes reports and sends alerts. Actions are enabled with `--auto-remediate` and affect only the services and folders you listed.
How can I preview actions without running them?
Run `python -m monitor.watchdog --dry-run`: it shows which actions auto-remediation would apply and executes nothing.
How do I install the watchdog as a service?
The `./scripts/install-watchdog.sh` script installs a systemd service. By default it only prints the plan and writing is enabled with `--yes`.
Where are incident reports kept?
In report files and a local SQLite database. The `python -m monitor.incident_db --search "nginx"` command finds past cases and `--prune` removes old ones.
Discussion
No questions or reviews yet.
Related
Skillshermesd shows Hermes Agent gateway, sessions, token spend, cron jobs and logs in one terminal, without writing to its state.
Telegram Dashboard for Hermes
hermes-agent-telegram-dashboard
A Hermes Agent plugin: agent state in one pinned Telegram message that is edited on a schedule. No Mini App and no model calls
Heinzel turns an agent into a cautious sysadmin for servers over SSH, with every command explained and approved first.
An agent runs servers through a catalog of declared actions: policy decides what runs and what waits for a person
HomelabHero turns a fresh LXC into a homelab command center with Claude Code and a credential broker in one command.
Forty-five skills, custom agents and CloudFormation templates for AWS DevOps Agent: incident analysis and operations reviews
README in short
The project began at a Hermes Agent hackathon by Nous Research and later gained a standalone mode. The repository holds the skill, the watchdog, a demo with ten training scenarios, a reinforcement learning environment and a test suite the author describes as 220 passing checks. Auto-remediation, quiet-hour alert suppression and adaptive thresholds are enabled with separate flags.
README badge
Original SKILL.md
---
name: incident-commander
description: >
Autonomous incident detection, root-cause analysis, and self-healing for
Linux/Docker production environments. Activate when the user mentions: server
down, high CPU, memory leak, disk full, service crash, deployment failure,
alert firing, on-call page, or any infrastructure emergency. Also activates
on scheduled health checks ("run a health check", "monitor my server").
Do NOT activate for general coding questions or non-infrastructure topics.
license: MIT
metadata:
author: hermes-incident-commander
version: "1.1"
tags: [devops, sre, monitoring, incident-response, self-healing]
---
# Incident Commander Skill
You are an autonomous Site Reliability Engineer. When an incident is detected
or reported, you follow the loop below **without waiting for further human
input** unless a destructive action requires approval.
## Core Incident Loop
```
DETECT → TRIAGE → DIAGNOSE → REMEDIATE → VERIFY → DOCUMENT → LEARN
```
### 1. DETECT
Gather signals immediately. Run all diagnostics in parallel via subagents
when possible:
```bash
# System vitals (always run first)
top -bn1 | head -20
free -h
df -h
uptime
systemctl list-units --failed
journalctl -p err -n 50 --no-pager
```
### 2. TRIAGE - Severity Classification
| Severity | Criteria | Response SLA |
|----------|----------|-------------|
| P0 | Total outage, data loss risk | Immediate |
| P1 | Partial outage, degraded service | < 5 min |
| P2 | Performance degraded, no outage | < 30 min |
| P3 | Warning thresholds, no impact | < 2 hours |