Unraid monitoring, Docker updates and a sysadmin bot on Telegram (3 workflows, built-in nodes only)

[SilentJMA]

TL;DR: three n8n workflows that monitor an Unraid server and let you manage it from Telegram. They use only n8n’s built-in nodes (Schedule, HTTP Request, Code, IF, Set, Telegram), so no community node is needed. They talk to Unraid’s official GraphQL API.

What you get

Workflow	Triggers	What it does
Alerts	Every minute (syslog) and every 5 minutes (health)	Sends each new problem to Telegram with suggested next steps and tappable follow-up commands. Repeats are throttled (60 min per alert). An unreachable API raises its own alert.
Docker updates & actions	Sundays 04:00, and called by the bot	Updates every container that has a new image, except the ones you exclude. Quiet when nothing changed.
Sysadmin & Telegram bot	Telegram Trigger	Answers /status, /info, /disks, /parity, /syslog, /notifications, /vms and forwards the Docker commands.

A Telegram bot has one webhook, so only the bot workflow has a Telegram Trigger.

What an alert looks like

(From the test simulation against a mocked server, not a live machine.)

🔴 CRITICAL · Tower

2 critical line(s) in /var/log/syslog (disk)

Oct 25 09:00:00 Tower kernel: critical medium error, dev sdb, sector 1
Oct 25 09:00:01 Tower kernel: md: disk0 read error, sector=1

Next steps
1. Identify the disk from the ataX / sdX / diskN in the line.
2. Run a SMART extended test on that disk and check reallocated / pending sector counts.
3. Reseat or replace the SATA/SAS cable and power cable; link resets are usually cabling.

Actions: /disks  /syslog  /status

From Real Message:

Requirements

• Unraid 7.2+ (the API is built in), or older Unraid with the Unraid Connect plugin
• An Unraid API key (Settings › Management Access › API Keys). Reads work with a read-only role. Updates, restarts and array/VM control need admin.
• A Telegram bot token from @BotFather

Setup

1. Create the API key. In n8n add a Header Auth credential: Name x-api-key, Value = the key.
2. Add a Telegram credential with the bot token.
3. Import the three JSON files and select the credentials in each workflow.
4. Set cfg.unraidUrl (for example https://192.168.1.10) in each workflow’s settings node. Use https: Unraid redirects http and the POST body is lost. The HTTP nodes accept the self-signed certificate.
5. Publish the bot workflow and message your bot. While cfg.allowedChatIds is empty, it only replies with your chat ID and runs nothing.
6. Put that ID in cfg.allowedChatIds (bot) and cfg.telegramChatId (the other two workflows).
7. In the bot’s Run Docker workflow node, pick Unraid · Docker updates & actions. Publish the Docker and Alerts workflows.

Keep n8n in cfg.excludeFromUpdates if n8n runs on the same server. Updating its own container cuts off the running execution.

Commands

Server	Docker
/status, /info, /disks, /syslog	/containers, /updates, /update_all (asks first)
/parity, /parity_start (asks first), _pause, _resume, _cancel	/update_<name>, /restart_<name>, /start_<name>, /stop_<name> (asks first)
/notifications, /archive_all, /vms, /help	/logs_<name>: last lines, analysed

Container names use underscores because Telegram commands only allow a-z0-9_ (Plex-Media-Server becomes /logs_plex_media_server).

Safety

Only chat IDs in the allow-list are served. Destructive actions ask for a confirmation tap. Each workflow has sticky notes explaining its sections.

Tested how

The command engine has unit tests, and a simulation runs all three workflows against a mocked Unraid API (first-run baseline, throttling, log rotation, revoked key, excluded containers, confirm-first actions). All scenarios pass. I have not posted numbers from a live server.

Optional AI triage uses n8n’s Basic LLM Chain and is off by default.

What’s next

I’m also finishing a dedicated community node for the Unraid API, npm: @silentjma/n8n-nodes-unraid (an Unraid action node plus an Unraid Trigger). The same three workflows rebuilt on it are shorter and easier to read, and that version will be updated regularly in the upcoming weeks.

Feedback welcome, especially on Unraid versions and log lines the rules miss.

Workflows: I couldn’t attach the workflows in the canva due to characters limitation but here you can find them ready for download.

unraid-sysadmin-bot.json (114.1 KB)

unraid-docker.json (208.3 KB)

Unraid · Alerts.json (127.3 KB)

[Shital_Katre]

Great work! I like the use of built-in n8n nodes, chat ID allow-listing, and confirmation steps for potentially destructive actions.

The separation between monitoring, Docker operations, and the Telegram command interface makes the system easier to understand and maintain. I also appreciate that the testing results are clearly distinguished from live-server performance.

I’ve been working on n8n + FastAPI + PostgreSQL workflows focused on idempotency, duplicate prevention, and failure recovery. Reliable error handling and safe execution are important across both types of automation.

Thanks for sharing this detailed implementation!

[TaskToAgent]

Nice setup, especially keeping n8n in excludeFromUpdates. Two things I’d add from running similar monitors:

1. Watch the watcher. If n8n runs on the same Unraid box, the failures you most want to hear about (Docker service down, array stopped, server frozen) also stop the Alerts workflow, so Telegram just goes quiet and quiet looks like “all good”. A free external dead-man’s switch covers that: put an HTTP Request at the end of the 5-minute health run that pings a check URL (healthchecks.io, or an Uptime Kuma push monitor on another machine), and let that service alert you when the pings stop for ~15 minutes.

2. Exclude n8n’s dependencies too. If n8n uses a Postgres or Redis container, an update restarting it mid-run cuts off the execution the same way updating n8n does. Before /update_all I’d also log each container’s current image digest (a Data Table is enough), so a bad Sunday update can be rolled back by pinning the old digest.

[SilentJMA]

@TaskToAgent There is still a long way to go, but I appreciate your feedback. There will certainly be more iteration for better results, but it also depends on each of us’s use case. Feel free to extend it and share it.