Get Told When a Synology or Unraid Disk Starts Failing

Disks almost never die without warning. They accumulate reallocated sectors for weeks, throw the occasional read error, and post a polite yellow triangle in a web interface that you last opened in February.

Then one drops out of the array, and now you are doing a rebuild with no redundancy, hoping the second-oldest disk holds for the eleven hours it takes. That whole situation was avoidable, and the only thing missing was a notification that reached you while the array was still healthy.

Unraid: add a notification agent

Unraid has a notifications system with built-in agents, and one of them is a plain webhook, which is all you need.

Create an application in TheNotificationApp, call it NAS, and copy the app_key. Then go to Settings, then Notification Settings.

Under agents, enable Webhook (in some versions it is listed under the Agents tab as a custom or generic webhook) and set the URL to:

https://thenotification.app/api/webhook/static/?app_key=YOUR_API_KEY&title=Unraid

Set the content type to JSON if the version you are on offers the choice. Test it from the same page before going further:

curl -X POST "https://thenotification.app/api/webhook/static/?app_key=YOUR_API_KEY&title=Unraid" \
  -H "Content-Type: application/json" \
  -d '{"event":"SMART","subject":"Disk 3","description":"14 reallocated sectors"}'

Then set the notification level. This is the field that decides whether the whole thing is useful:

• Warnings and Alerts: what you want. Disk temperature, SMART attribute changes, array problems, parity check results.
• Notices as well: what you do not want. This includes routine informational events and will train you to ignore the channel.

Also set the SMART attribute thresholds under Settings, then Disk Settings. The one to care about is reallocated sector count: any movement above zero is worth a notification, because a healthy disk stays at zero for its entire life.

Synology: a scheduled task

Synology's own notification system is email and its push service, with no generic webhook option. So this one takes a small script instead, run from Task Scheduler.

Go to Control Panel, then Task Scheduler, then Create, then Scheduled Task, then User-defined script, and run it as root, daily.

#!/bin/sh
# SMART reallocated-sector watch for Synology
APP_KEY="your_app_key_here"
STATE="/volume1/homes/admin/.smart-state"
HOST="$(hostname)"

notify() {
  curl -fsS --max-time 10 -X POST https://thenotification.app/api/sendNotification \
    -H "app_key: $APP_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"title\": \"$1\", \"body\": \"$2\"}" >/dev/null
}

touch "$STATE"

for dev in /dev/sata* /dev/sd?; do
  [ -e "$dev" ] || continue
  name="$(basename "$dev")"

  count="$(smartctl -A "$dev" 2>/dev/null \
           | awk '/Reallocated_Sector_Ct/ {print $10; exit}')"
  [ -z "$count" ] && continue

  prev="$(grep "^$name " "$STATE" | awk '{print $2}')"
  [ -z "$prev" ] && prev=0

  if [ "$count" -gt "$prev" ]; then
    notify "$name: reallocated sectors rising" \
           "[$HOST] now $count, was $prev. Plan a replacement."
  fi

  sed -i "/^$name /d" "$STATE"
  echo "$name $count" >> "$STATE"
done

The state file is what makes this a warning rather than a nag. It notifies when the count increases, not when it is non-zero, so a disk that has sat at 8 reallocated sectors for two years stays quiet, and the day it moves to 9 you hear about it.

Device naming varies across Synology models and DSM versions, which is why the loop covers both /dev/sata* and /dev/sd?. Run ls /dev/sd? /dev/sata* on your box first and adjust if neither matches.

What is actually worth alerting on

A NAS can tell you a great many things. Four of them are worth a notification:

• Reallocated sectors increasing. The earliest reliable warning. Weeks of notice.
• A disk dropped out of the array. Redundancy is gone. This is the emergency.
• Parity check or scrub found errors. Something is wrong with data you thought was safe.
• Volume above 90% full. Boring, and the most likely of the four to actually happen.

Not on the list: temperature within normal range, successful parity checks, completed backups, anyone logging in. Those are for the dashboard.

The honest part

This is a genuinely low-volume setup. A healthy NAS sends zero notifications for months, which is exactly the point, and means the free tier of 100 for the lifetime of the account will last for years.

The one thing that ruins it is alerting on a threshold rather than a change, like notifying whenever reallocated sectors are above zero. That sends a daily notification about a disk you already decided to keep, forever. The state file exists for that reason.

Pro is $2.99 a month for 1,000 if you have several boxes. And the honest limitation: a SMART attribute is a hint, not a guarantee. Plenty of disks fail with a clean SMART report, which is an argument for backups rather than an argument against the alert.

Where this fits

The same one-line POST as everything else, pointed at a disk instead of an exit code. If your NAS also runs containers, the crash-alert version is in Docker container alerts, and the request shape is in the API reference.

Grab a key at thenotification.app and find out about a dying disk while you still have redundancy.

New to this? Start with the server-down alert this is built on.