Install Uptime Kuma on Synology and Monitor Your Services
Deploy Uptime Kuma with Container Manager, configure the DSM firewall and reverse proxy, then create your first monitors and notifications.
Uptime Kuma turns a Synology NAS into an autonomous monitoring station. As long as the NAS and its network are running, it continuously checks the websites, servers, databases, and other services you entrust to it, keeps their history, and notifies you quickly when a check fails.
Why use Uptime Kuma
Uptime Kuma is an open-source availability monitoring application. It acts as a personal alarm: it checks that a website, server, or network service is still responding and triggers a notification as soon as its state changes.
The need is simple: know when a site stops responding, monitor the quality of an Internet connection, or measure the availability of equipment at an operator's site. Instead of discovering the outage by chance, you immediately receive an alert via messaging, email, or one of the many compatible services.
Uptime Kuma notably includes the following features:
- checking HTTP and HTTPS domains, with optional keyword search within the page;
- monitoring DNS records, Docker containers, and databases such as MySQL, MariaDB, or Microsoft SQL Server;
- responsive, clear, and fast-to-navigate interface;
- manual dark mode or synchronized with the system theme;
- latency graphs and availability statistics over time;
- alerts to many services, for example Telegram, Slack, Discord, Microsoft Teams, Signal, Gotify, Ntfy, Opsgenie, or PagerDuty;
- proxy support for checks that must go out through an intermediary;
- check interval down to 20 seconds when the monitor type allows it;
- interface translated into many languages, including French;
- public status pages to inform users or announce maintenance;
- tracking of TLS certificate expiration and account protection by two-factor authentication.
I had been looking for a solution of this type for a long time. Hosted services were either paid or too limited for my use. Here, the number of monitors depends mainly on the NAS resources and the chosen frequency, while the monitoring and notification modes cover most needs of a small network or a home lab.
Prepare persistent folders
In the docker share, create an uptime-kuma folder, then an data subfolder. The database, settings, tracked certificates, and instance configuration will be kept there, outside the container.
Create the project in Container Manager
Open Container Manager → Project → Create. Name the project kuma, select the path /docker/uptime-kuma, choose to create a docker-compose.yml file, then enter the following configuration:
services:
uptime-kuma:
image: louislam/uptime-kuma:2
restart: unless-stopped
volumes:
- ./data:/app/data
ports:
# <NAS port>:<container port>
- "3005:3001"
environment:
TZ: Europe/BrusselsThe major tag :2 follows the stable branch of Uptime Kuma 2. At the time of this check, the published stable version is 2.5.3. If you prefer to manually validate each update, replace the major tag with a specific version, then return to the :2 tag when your testing procedure is ready.
Validate the project. Container Manager downloads the image, creates the Docker network, and starts the service. The message Exit Code: 0 means that the creation completed without error. Then check that the container appears in the active state.
Configure the DSM firewall
If the DSM firewall is enabled, the container must be able to reach the targets to be monitored. In Container Manager → Network, expand kuma_default and note its subnet. The capture shows 172.18.0.0/16; the mask /16 corresponds to 255.255.0.0.
Add a DSM rule adapted to this subnet and the necessary destinations, then place it before the deny rules. Do not blindly copy 172.18.0.0/16: Docker may choose another range if it is already occupied. Also avoid allowing all ports to the entire network when Kuma only needs a few internal services.
Publish Kuma with the reverse proxy
To access Uptime Kuma via a domain name, open Control Panel → Login Portal → Advanced → Reverse Proxy, then create a rule. The original article mentioned Joplin here by mistake: the destination is indeed the Uptime Kuma server.
- Source: HTTPS protocol, host name such as
kuma.exemple.be, port443. - Destination: HTTP protocol, host name
localhost, port3005. - Custom header: choose Create → WebSocket to automatically add
UpgradeandConnection.
First create the DNS record for kuma.exemple.be and assign a valid TLS certificate for this subdomain to the proxy. Uptime Kuma uses WebSocket: without the two headers shown in the capture, the interface may load while remaining unable to connect to the server. Use a dedicated subdomain rather than a path like /uptime-kuma, which is not officially supported.
Perform the initial configuration
Open https://kuma.exemple.be. As long as port 3005 is accessible from your administration network, you can also use http://IP-DU-NAS:3005 for the first diagnosis. The Joplin URL present in the source article was a typo and has been corrected here.
On the first start, choose the French language then the database engine. SQLite remains the simplest choice for a small installation and the one used in this configuration. Uptime Kuma 2 also offers embedded MariaDB or an external MariaDB/MySQL server. Choose from the start with full knowledge of the facts: direct migration from an existing SQLite database to MariaDB is not officially supported.
Then create the first administrator account. Use a non-obvious username, a unique password stored in a manager, then enable two-factor authentication in the settings as soon as access is validated.
Add monitors and notifications
Click New Monitor, choose the check type, and fill in the target. For a website, start with HTTP(s), enter its URL, select an interval, and keep reasonable timeouts. The "keyword" mode is useful when a simple HTTP 200 code is not enough to prove that the correct page is served.
You can then create Ping, TCP, DNS, Docker, MQTT, gRPC, SNMP, or database checks according to your needs. Organize them by groups and tags, name them clearly, then create a separate status page if users need to check availability without accessing the administration dashboard.
In Settings → Notifications, add at least one channel and send a test alert. Telegram, Signal, Slack, Teams, Gotify, Ntfy, Pushover, and many other providers are available. Then associate the notification with the relevant monitors; creating the provider does not automatically activate it everywhere.
Finally, test a real transition: briefly stop a non-critical service, wait for the unavailability alert, restart it, and check the return-to-normal notification. This check prevents discovering, during a real outage, that a token or a destination address was incorrect.
Limits and maintenance
This installation has been running for a long time with several tens of services and consumes few resources. The final capture indicates about 180 MB of memory and less than 1% CPU at this instant; however, requirements vary depending on the number of checks, their frequency, notifications, and retention duration.
Back up the data folder before any update. In Container Manager, pull the new image then recreate the project with the same volume. Consult the release notes, check the dashboard, and trigger a test notification after each change.
Conclusion
Uptime Kuma is now installed on the Synology NAS, accessible in HTTPS behind the reverse proxy, and ready to monitor your services. All that remains is to create the useful checks, adjust their frequency, associate the alerts, and regularly verify that backups and notifications actually work.
References
Read next
About the author
Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.
Discussion
Comments
No comment yet. Feel free to open the discussion with a question or your own experience.