NAS SETUP, MAINTENANCE & RECOVERY
A storage warning helps only if it reaches someone before the next failure. Configure Synology notifications around the events that need action, the people who can respond and the channels that remain available during an outage. A test email is the beginning of verification, not proof that every backup or disk warning is covered.
Quick answer
In DSM, open Control Panel → Notification, configure a supported email, push or webhook route, and select the relevant event rules. Send a test and confirm delivery to the actual recipient. Review backup-package reporting separately, protect sender credentials, and retest after account or network changes. An alert sent from the NAS cannot report every incident that prevents the NAS itself from running.
Steps to follow
-
Decide which events require action
List the conditions that matter for this installation: degraded storage, disk errors, low capacity, failed backups, abnormal shutdowns and important account events. Decide who owns each response and how urgently it must be reviewed. A household archive and a business service may need different coverage, but both benefit from a clear person responsible for checking the message.
Separate immediate warnings from routine information so the recipient does not learn to ignore the channel. Record the NAS name, location label and service role in a non-sensitive inventory. A message saying disk warning is less useful when several machines have the same default name. Choose identifiers that are recognisable without including private folder names or credentials in notification subjects.
-
Configure the supported delivery route
Open Control Panel and Notification in the installed DSM release. For email, use the supported sender or Synology Account option and recipient profiles presented by that version. Complete any provider authorisation through the normal sign-in route. Do not paste your ordinary password into an outdated SMTP example if the provider now requires another supported authentication method.
For a webhook, create the endpoint using the receiving service's documented integration and store its URL as a secret if it grants posting access. DSM7 supports notification webhooks, but provider templates and options can vary. Choose a channel whose membership is appropriate for operational messages. A broadly shared chat room may reveal more system details than the intended maintenance team needs.
-
Select event rules and test the actual recipient
Choose or create a rule for the events this profile should receive, then save it. Send the interface's test message and confirm it arrives at the destination account or channel. Check spam filtering, notification permissions and muted conversations if it does not appear. Record the time and NAS identity so you know the message came from the configuration being tested.
Inspect the event selection separately after delivery succeeds. A working email connection does not establish that degraded-storage events are included. Likewise, a successful webhook test does not prove that an application's own alerts use that profile. Review the backup or storage package's reporting settings and logs rather than assuming every service automatically inherits the system notification choices.
-
Rehearse a harmless operational response
Use a supported test facility or a low-risk, controlled event where available; do not disconnect a live RAID member just to generate a warning. Ask the responsible person to identify the NAS, read the event and locate the relevant log. Confirm that the response procedure is understandable without handing them unrestricted administrator credentials unnecessarily.
Document what to do if the notification route fails, including how to inspect local logs and contact the system owner. Retest after changing the sender account, recipient, router, DNS or DSM version. Keep a dated check record. A configuration saved months ago is not evidence that current authentication, provider access and recipient notifications still work.
Detailed guidance
Distinguish delivery failure from an unselected event
If no test message arrives, investigate the delivery channel: authorisation, endpoint, recipient, network access and provider response. If tests arrive but a particular warning does not, inspect its event rule and the application that generated it. These are different faults. Changing the SMTP password repeatedly will not add an omitted event to the selected rule.
Use timestamps to compare DSM logs with the receiving service. Check whether the system clock is correct, especially when authentication or certificates are involved. Preserve the exact error without publishing tokens or credentials. A short record of the attempted message, response and destination profile is more useful for support than repeatedly recreating the entire configuration.
The alert route should not depend entirely on the failing NAS
A webhook sent to a chat service hosted only on the same NAS can fail at the same time as the event it should report. Email or another independent destination can reduce that shared dependency. Even then, a powered-off machine cannot send a new alert after losing all power and connectivity. Consider separate availability monitoring where knowing that absence matters.
For a UPS event, test the supported monitoring and orderly-shutdown arrangement without risking production data. Review the event history after the exercise and confirm the recipient understands what happened. A battery-backed NAS with a disconnected notification path can still shut down correctly while leaving its owner unaware of the outage.
Keep notification access maintainable
Use a sender or integration whose ownership is clear and review it when staff or household responsibilities change. Remove obsolete recipients and rotate exposed webhook secrets through the receiving service's supported process. Keep the updated recovery record protected. Avoid using one person's private mailbox as an undocumented permanent dependency for an organisation's storage alerts.
Review alert volume periodically. Repeated low-value messages can hide the important ones, while an overly narrow rule can suppress early warnings. Adjust the policy using actual events and response experience. The aim is a small, reliable stream of understandable notices that leads to action, supported by logs and a known recovery plan.
Compare the options
| Situation | Recommended action | Check before continuing |
|---|---|---|
| Test message never arrives | Check sender authorisation, endpoint and recipient filtering | Do not assume event rules are the cause |
| Tests arrive but a backup failure does not | Review package reporting and selected events | Delivery and event coverage are separate checks |
| Alerts go to a service on the same NAS | Add an appropriate independent route | A shared outage can silence both systems |
| Too many routine messages | Separate urgent warnings from informational rules | Retain important storage and backup failures |
Frequently asked questions
Does a successful test email prove all alerts are working?
No. It verifies that the chosen delivery route worked for that test. Confirm which events use the profile and inspect package-specific reporting. Repeat a harmless supported test after significant configuration changes.
Can DSM notify me after the NAS loses all power?
The NAS cannot generate and send a new message while it is completely unavailable. A UPS may provide time for supported alerts and shutdown, while independent monitoring can detect loss of service. Plan for those separate failure conditions.
Official documentation
This guide combines current official documentation with practical recovery checks. It does not claim hands-on testing of your installation. Menu labels and supported procedures can vary by release; follow the documentation for your installed version.