Home | Contact
whichnas.com

Schedule a Weekly Health Check Script on Your Synology NAS

For Australians running a Synology NAS at home or in a small business, a quiet weekly health check can save hours of troubleshooting when something eventually goes wrong. Drives fail without warning, RAID arrays drift out of sync, and DSM updates occasionally leave behind minor configuration quirks that only surface under load. Rather than waiting for warning lights, owners from Perth to Brisbane can automate a short script that inspects the system every Sunday morning and emails a tidy summary to their inbox.

The Synology DSM operating system ships with a built-in Task Scheduler that accepts ordinary bash scripts, the same engine used to schedule cron jobs on Linux. That means almost any maintenance routine a sysadmin would write for a Linux server can be ported across with very little modification. Once the script is uploaded and assigned a schedule, it runs quietly in the background using the NAS's own resources, leaving front-of-house services like Plex, Photos, or Surveillance Station completely unaffected.

A weekly cadence tends to fit Australian usage patterns well. Daily checks generate noise and bloat the system logs without offering much extra value, while monthly intervals risk missing the early symptoms of a degrading SMR drive or a flaky SSD cache module. Running the routine on a weekend morning, before the household wakes up in Sydney's suburbs or before a Melbourne office opens its doors, gives the script time to finish before users begin streaming files or pulling backups.

The good news is that none of this requires advanced programming knowledge. Anyone comfortable editing a text file in Notepad or TextEdit and copying a few commands can put together a meaningful check, and the steps below walk through the entire setup from first boot to the first scheduled run.

Preparing the DSM environment for scripted checks

Before writing any code, it helps to make sure DSM itself is configured to accept automated tasks. Open Control Panel, then head into Terminal and SNMP to enable the SSH service, which is the cleanest way to upload and edit scripts. If SSH feels too exposed, the alternative is to mount the NAS as a network share from a Windows or macOS workstation and drop the script into a dedicated folder such as /volume1/scripts/. Either approach works, but SSH gives more control over file permissions and makes later debugging easier.

A second step is to confirm that the user running the schedule has the right privileges. The default admin account will work in most cases, but for stricter environments a dedicated maintenance account belonging to the administrators group is cleaner. Create one through Control Panel, User and Group, assign it a strong password, and then grant it the right to run scheduled tasks under Privileges, Application Privileges.

Finally, take a moment to set the NAS time correctly. Australian operators sit across AEST, ACST, and AWST, and Tasmania, Victoria, NSW, SA, and the ACT observe daylight saving between October and early April. If the system clock is out by even a few minutes, weekly scripts can fire at unexpected hours. Open Control Panel, Regional Options, and pick the correct time zone, then enable NTP synchronisation with time.google.com or pool.ntp.org to keep the clock honest across the year.

Writing the health check script

A solid script for a Synology box typically checks three things: drive SMART status, RAID or storage pool integrity, and DSM system load. SMART data is the most useful early-warning signal because most consumer NAS drives report rising reallocated sectors long before they actually fail. A one-liner using smartctl, which is bundled with DSM and located in /usr/syno/bin/ or /usr/bin/, will pull this data for every disk in the chassis.

The second section of the script should examine the storage pool or RAID array. Tools like /usr/syno/bin/synospace or /usr/syno/sbin/synolog report volume usage and degraded arrays, while cat /proc/mdstat exposes the underlying Linux software RAID state for SHR and JBOD setups. Pairing these outputs gives a complete picture without relying on a single vendor command.

The third block records CPU temperature, fan speeds, and memory pressure using synosystemctl or simple /sys/class/hwmon/ reads. Australian summers push roof cavities and home offices well past 35 °C, and a NAS humming away at 50 °C will shorten drive life noticeably. Logging these figures weekly creates a temperature trend line that makes anomalies easy to spot when comparing October to March readings.

Save the finished file as healthcheck.sh in the scripts folder, then make it executable with chmod +x healthcheck.sh. A quick manual run from an SSH session, using ./healthcheck.sh, confirms that each command produces sensible output before the routine is committed to a schedule.

What a typical health check script monitors

Using Task Scheduler to automate the script

With the script in place, DSM's Task Scheduler handles the rest. Open the application from the main menu, click Create, Triggered Task, User-defined script, and give the task a name such as Weekly NAS Health Check. Choose the maintenance user created earlier from the User dropdown so the task runs with the right privileges.

Under the Schedule tab, set the task to run Weekly, pick Sunday at 7:00 am local time, and confirm that the Recurring option stays selected. The Task Settings tab is where the script path goes, written in the form bash /volume1/scripts/healthcheck.sh. Tick Send run details by email and add a valid address, since this is the simplest way to receive results without building custom notification logic.

One often-overlooked option lives in the General tab: the Enable checkbox must remain on, otherwise the schedule silently does nothing. After saving the task, right-click it and select Run to trigger an immediate manual execution. If the email arrives within a couple of minutes, the schedule is wired up correctly and the weekly automation can be left to run itself. For users who prefer a graphical alternative, Synology's Active Insight service and container packages such as Uptime Kuma offer richer dashboards once the basic scheduled script is working.

Useful DSM tools for verifying your setup

Notifications and alerting options

Email is the default channel in Task Scheduler, but Australian small business operators often want push notifications on their phone as well. Synology's mobile apps, including DS File and Synology Photos, can be linked to a Synology Account so that DSM forwards alerts through the Push Service. This requires that the Synology Account be registered with the NAS under Control Panel, Notification, and it does not depend on SMTP credentials, which is helpful for offices without an on-premise mail server in places like Hobart or Townsville.

For environments that already use Microsoft 365 or Google Workspace, configuring SMTP relay through those providers gives reliable email delivery and keeps audit trails inside the organisation. A small Australian IT support outfit in Adelaide can set this up in roughly ten minutes using app passwords, and the resulting alert emails show up with proper SPF and DKIM signatures, reducing the chance of them being filed as spam by Telstra or Optus mail servers.

A third layer worth considering is integration with local monitoring platforms such as Nagios, Zabbix, or the open-source Healthchecks.io service. These tools track routine execution and alert the administrator if a weekly script fails to run on time, which is especially valuable for unattended sites such as regional offices in Cairns or Darwin where nobody checks the NAS in person.

Troubleshooting and fine-tuning the routine

When a scheduled script does not run as expected, the first stop is Log Center. Filter by the task name, look for lines tagged as error or failure, and check whether the entry shows a non-zero exit code. A common cause is a path typo, since DSM is strict about whether /volume1 is capitalised or whether .sh is included in the filename.

Another frequent issue is permission denial, particularly when the script writes to a folder the scheduling user cannot reach. Storing all logs inside a dedicated directory such as /volume1/scripts/logs/ and granting the maintenance user write access resolves most of these cases. If the script needs root-level commands like smartctl, prefix them with sudo and confirm that the maintenance user belongs to the administrators group.

Lastly, keep an eye on the script's runtime. A check that takes ten minutes is fine, but one that climbs past thirty usually signals that an underlying service is stuck or a SMART test is running longer than expected. Adjusting the schedule to a less busy hour, or splitting the check into two smaller scripts running on alternate weeks, keeps resource pressure low. After a month of clean runs, lock the configuration down by disabling SSH if it is no longer needed and enjoy a Synology system that looks after its own health on autopilot.

Share your weekly health check routine with the WhichNAS community, swap script snippets with other Australian owners in the comments, and bookmark this guide for the next time you set up a fresh DSM installation.