Bottom Line: Do Not Rely on the ZimaOS Dashboard Alone for RAID Failure Awareness
A RAID can stay online in degraded mode after one member fails, which is exactly when a user is most likely to miss the problem if they only notice it during a later login. The practical monitoring stack is to keep ZimaOS Storage as the configuration source, then add an independent SMART/drive-health monitor that can push alerts to a phone, Discord, email or webhook.
The 2026 thread used Scrutiny plus ntfy. That remains a sensible design because Scrutiny can inspect physical-drive SMART data and supports multiple notification transports.
Install a Drive-Health Monitor That Can See the Physical Disks
Scrutiny needs access to the actual SATA/NVMe devices, not only a mounted filesystem. In Docker, verify that the app has the required /dev/sdX or /dev/nvmeX devices and that SMART collection succeeds. If the disks sit behind an HBA, USB bridge or RAID controller, the collector may need controller-specific handling.
smartctl -H /dev/sda
smartctl -a /dev/sda
nvme smart-log /dev/nvme0Scrutiny's Scrutiny notifications lists email, webhooks, Discord, Gotify, ntfy, Slack, Telegram and other destinations. The Netdata monitoring covers host metrics that SMART does not.
Test ntfy Before Connecting It to SMART Events
First prove that the phone receives a plain test message:
curl -d "Zima drive alert test" https://ntfy.sh/YOUR_UNIQUE_TOPIC
Use a hard-to-guess topic name or authenticated self-hosted ntfy if the alert content is sensitive. Public ntfy topics should not be treated as secret merely because you chose a memorable name.
Connect Scrutiny to the Alert Destination
Current Scrutiny releases support notification URLs through scrutiny.yaml. Keep the notification configuration in persistent AppData so container recreation does not silently remove alerting. After changing it, restart Scrutiny and call its notification health check:
curl -X POST http://SCRUTINY_IP:PORT/api/health/notifyA successful test notification is important because a green SMART dashboard does not prove the outbound notification channel works.
Monitor RAID State Separately From SMART Health
SMART can warn about a physical drive, but RAID degradation is an array-level state. A disk can disappear suddenly without giving a useful pre-failure SMART warning. Check both:
cat /proc/mdstat
mdadm --detail /dev/md0The Linux mdadm RAID status is the array-level reference. The RAID recovery covers the ZimaOS-side recovery boundary.
Define Alerts That Tell You What to Do
Do not send the same vague “disk problem” message for everything. Useful alerts distinguish at least: SMART critical warning, disk missing, RAID degraded, RAID rebuilding, filesystem nearly full and storage temperature above your chosen threshold. Include device model/serial and array name when possible so you know which drive to inspect before opening the chassis.
Do Not Wait for SMART to Become Your Backup Strategy
A drive can fail without a long SMART warning, and RAID does not protect against deletion, ransomware or chassis loss. Keep a second verified copy of irreplaceable data. The ZimaOS backup addresses the recovery layer that monitoring cannot replace.
Use a Second Uptime Monitor for the Monitoring Stack Itself
If Scrutiny or ntfy stops running, the absence of alerts can look like “everything is healthy.” Monitor the Scrutiny web endpoint or notification service with a simple uptime check. The Uptime Kuma monitoring is useful for that meta-monitoring layer.
FAQ
Does ZimaOS email me when a RAID disk fails?
Do not assume dashboard visibility equals outbound alerting. Add an independent notification path and test it end to end.
Can Scrutiny detect RAID degradation?
Scrutiny primarily evaluates physical-drive SMART data. Check mdadm/ZimaOS array state separately for degraded RAID.
What if SMART says a failed drive is healthy?
A disk can disappear because of power, cabling, controller or sudden electronics failure without a predictive SMART warning. Monitor device presence and RAID state too.
Is ntfy safe for drive alerts?
Yes when configured appropriately. Use a unique or authenticated topic, especially if notifications include hostnames, serial numbers or other infrastructure details.
How often should SMART be checked?
Daily is common for full collection, while critical device/array presence can be checked more frequently. Avoid excessive tests that add unnecessary disk activity.
