How to monitor a Synology NAS from outside your network

What DSM will not tell you

DSM notifications are genuinely good. They will tell you about a failing drive, a full volume, a finished backup. They tell you nothing once DSM stops running or the NAS loses its network path, which is most of the outages that actually cost you something.

• A DSM update that reboots and never completes, discovered hours later when a container on another host starts throwing NFS timeouts.
• A volume going read only or crashing, which leaves DSM answering while every share is useless.
• The NAS dropping off the network after a switch reboot, so nothing is wrong with the NAS and everything is wrong for its clients.
• A scheduled Hyper Backup task that silently stops running. DSM reports failures, but a task that never fires produces no failure to report.

That last one is the sneakiest, and it is why a heartbeat belongs on your backup job as well as on the NAS.

What to check

DSM 7 serves its interface on port 5000 for HTTP and 5001 for HTTPS. Many people move those, so confirm yours first. SSH, when enabled, sits on 22 unless you moved it, and Synology suggests you do.

DSM publishes no purpose built health endpoint, so the honest option is the API discovery call. Synology states in its Login Web API guide that SYNO.API.Info is the only API with a constant URL and that it does not need authorization. It returns JSON listing every installed API with a success flag:

curl -fsSk 'https://nas.example.com:5001/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=all'
# {"data":{"SYNO.API.Auth":{"path":"auth.cgi","minVersion":1,"maxVersion":7}, ... },"success":true}

That beats a bare port probe. A JSON check asserting success is true proves DSM is serving real API responses, not merely accepting a TCP connection. For keyword matching, SYNO.API.Auth is a stable string.

Authenticated calls are possible: DSM 7 routes logins through /webapi/entry.cgi with the SYNO.API.Auth API, returning a session id to reuse. That is more moving parts than a monitor needs. Save it for a dashboard.

DSM presents an untrusted certificate until you install a real one, so an SSL check against a stock install fails chain validation. Install a proper one and that check becomes a useful expiry alarm instead of permanent noise.

Do not expose DSM just to check it

Publishing the DSM login page to the internet is a bad trade, and QuickConnect exists so you do not have to port forward. Neither is a monitoring plan: QuickConnect is a relay for you, not a health signal.

Check from the inside out instead. Synology Task Scheduler runs user defined scripts on a schedule, so you need neither SSH nor cron:

curl -fsS -m 10 https://undownable.com/ping/your-monitor-id > /dev/null

If DSM stops running tasks, or the NAS loses power, or its route to the internet disappears, the pings stop and you get an incident from a service nowhere near your house.

To prove more than uptime, gate on a local check first, so it fails the moment the web stack stops answering even if the kernel is fine:

curl -fsSk -m 10 -o /dev/null \
  'https://127.0.0.1:5001/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=all' \
  && curl -fsS -m 10 https://undownable.com/ping/your-monitor-id > /dev/null

Better still, gate on something you actually rely on. A write test turns the heartbeat into a volume health alarm:

touch /volume1/docker/.heartbeat \
  && curl -fsS -m 10 https://undownable.com/ping/your-monitor-id > /dev/null

A read only volume fails the touch, the ping never goes out, and you learn about it before the containers elsewhere fall over.

Cover the backup job too

Add a second heartbeat monitor with a long interval, say 26 hours for a nightly job, pinged from a follow on task after Hyper Backup. A job that fails gets reported by DSM; a job that stops being scheduled gets reported by nothing, which is how backups quietly become a year old.

Alerts that arrive when the NAS does not

DSM email is worth enabling and not worth relying on alone. External delivery reaches you regardless of what happened to the NAS or the link:

• ntfy, self hosted or hosted, with an access token beginning with tk_ sent as a bearer token and stored encrypted. Do not run that server on the NAS you are monitoring.
• Telegram, the pragmatic pick when the NAS is where all your other services live.
• Email, slow but durable, and it survives you changing phones.

Confirmation thresholds keep a DSM update from waking you, and a maintenance window keeps planned reboots out of your incident history.