How to teach n8n to fix crashed services on your server for you

Familiar scene: a container with a database or media server crashes in the middle of the night. You wake up to an alert, open the terminal, check the logs, restart the crashed service, and go back to sleep in a bad mood. Regular monitoring only knows how to send panic messages. It sees the symptom but doesn't even try to figure out the causes.

Popular tech blogger NetworkChuck released an interesting repository called n8n-terry-guide. Inside is a step-by-step guide for building Terry. This is a virtual sysadmin inside n8n that checks services, SSHs into servers to examine logs, and asks you in Telegram for permission to restart.

The idea sounds fun, but behind it is a practical agent architecture that's easy to replicate on your own server.

Who is Terry and why this isn't just another bot

Usually, homelab automation is built on rigid scripts. Service crashes — trigger the docker restart command. If the port is occupied by another process, the script breaks and starts spamming errors.

The LLM-agent approach works differently. The author suggests training the model like a support trainee, gradually expanding its responsibilities. In the repository, the entire process is broken down into five evolution stages:

1. Basic checker. The agent pings an HTTP endpoint and checks for a specific HTML tag.
2. Diagnostician. If the service is unavailable, Terry connects via SSH, runs docker ps, retrieves the exit code and the last lines of logs.
3. Automatic repairman. The model tries to bring up the crashed container and re-checks the site availability.
4. Troubleshooter. The agent encounters a port conflict, finds the culprit process using system utilities, and makes a decision.
5. Human-in-the-Loop. The model finds the cause of the failure, forms an action plan, and waits for confirmation from the owner in the messenger.

The main feature here is the fifth stage. No sane person would give a language model root access without control. Terry can perform diagnostics independently, but any modifying commands must be approved.

How the n8n internals are wired together

All logic is built using standard n8n nodes without writing custom TypeScript or Python code.

At the center of the scheme is an AI Agent node with a connected GPT-4o-mini model and a Simple Memory block. For executing commands on the server, the author came up with an elegant solution: a separate subworkflow with an SSH node.

When the agent needs to check the system state, it calls this subprocess as a Tool, passing the required command:

docker inspect website --format='{{.State.ExitCode}}'
docker logs website --tail 10

To automate checks, a Schedule Trigger is placed before the agent, launching the scenario every 5 minutes. To prevent the dialogue from turning into a mess of arbitrary text, a Structured Output Parser is used at the model output. The agent must return JSON in a strictly defined format:

{
  "website_up": false,
  "message": "Контейнер остановлен из-за нехватки памяти",
  "applied_fix": false,
  "needs_approval": true,
  "commands_requested": "docker start website"
}

Thanks to the strict structure, the next node IF or Switch instantly understands if everything is fine. If a breakdown is detected, the scenario sends a message to Telegram with confirmation buttons. Pressed "Yes" — n8n returns control to the agent, and it performs the fix.

Connecting real hardware

The author didn't limit themselves to a test site on Nginx. The guide includes system prompts and command examples for four popular systems:

• Proxmox hypervisor. The agent gets node status, list of VMs via pvesh get /nodes, and checks LXC containers.
• UniFi network equipment. Requests to the UniFi Network API for monitoring access points, client count, and traffic consumers.
• Network Attached Storage (NAS). Checking SMART attributes of disks via smartctl, reading RAID array status from /proc/mdstat, and checking critical errors in journalctl.
• Plex media server. Checking the web interface and proper restart when it hangs.

For disks and NAS, Terry is configured to work strictly in read-only mode. The prompt explicitly forbids executing formatting, remounting, or pool-stopping commands.

Pitfalls you might encounter

If you decide to deploy such a scenario on your own, pay attention to a couple of nuances that are often forgotten when configuring AI agents.

First, the iteration limit. By default, the AI Agent node in n8n makes up to 10 tool calls per run. If the agent gets confused by the output of netstat or docker ps, it will quickly exhaust the limit and crash with an error. Prompts need to be as specific as possible, narrowing the field for experiments.

Second, session passing. When running on a schedule, you don't have a live chat, so the session ID chatId needs to be hard-generated in an intermediate Edit Fields node before sending to the agent's memory. Otherwise, the context of previous checks will be lost.

Third, the so-called God-Mode. In the repository, there's a prompt with full rights for automatic fixing of any problems. Enabling this on a production server is definitely not worth it: the model can easily delete a needed container to free up an occupied port.

Is it worth trying

The repository n8n-terry-guide doesn't contain ready-made workflow export files — it's a collection of configurations, step-by-step instructions, and refined prompts. If you already run n8n for home or work needs, the guide gives an excellent framework for creating an on-call assistant.

The project will appeal to those tired of stupid alerts and wanting to receive in Telegram not just a scream of "service crashed," but a ready diagnosis with a "fix it" button. Start small: configure checking of one test container, try out the Telegram integration, and evaluate how convenient it is to delegate routine tasks to a language model.