When you start self-hosting more than one service, monitoring becomes very important.<\/p>\n\n\n\n
At first, it is easy to check everything manually. You open your website, check your dashboard, SSH into the server, run a few commands, and hope everything is fine.<\/p>\n\n\n\n
But once you have multiple services running, manual checking is not enough.<\/p>\n\n\n\n
I wanted a simple way to know:<\/p>\n\n\n\n
Is my video server online?\nIs my reverse proxy working?\nIs my admin dashboard protected?\nAre my virtual machines reachable?\nIs my monitoring server itself healthy?\n<\/code><\/pre>\n\n\n\nFor this, I built a dedicated private monitoring server using Uptime Kuma<\/strong>.<\/p>\n\n\n\nThis article explains what Uptime Kuma is, why I installed it on a separate VM, how the architecture works, and the main lessons I learned while building it.<\/p>\n\n\n\n
\n\n\n\nWhat Is Uptime Kuma?<\/h2>\n\n\n\n
Uptime Kuma<\/strong> is an open-source monitoring tool that lets you watch websites, servers, APIs, ports, and internal services from a clean web dashboard.<\/p>\n\n\n\nIt can monitor things like:<\/p>\n\n\n\n
HTTPS websites\nInternal HTTP services\nPing checks\nTCP ports\nDocker services\nSSL certificate status\nLogin-protected dashboards\n<\/code><\/pre>\n\n\n\nIt gives you a visual dashboard showing what is:<\/p>\n\n\n\n
UP\nDOWN\nPending\nSlow\nUnavailable\n<\/code><\/pre>\n\n\n\nIt can also send alerts later through email, Telegram, Discord, Slack, webhooks, and other notification channels.<\/p>\n\n\n\n
In simple words, Uptime Kuma is like a watchman for your server.<\/p>\n\n\n\n
Instead of wondering whether your services are working, you open one dashboard and see the status clearly.<\/p>\n\n\n\n
\n\n\n\nWhy I Used a Separate VM for Monitoring<\/h2>\n\n\n\n
I did not want to install monitoring directly on the Proxmox host.<\/p>\n\n\n\n
The Proxmox host should stay clean. It should only run virtualization, storage, networking, and core host services.<\/p>\n\n\n\n
So I created a separate virtual machine just for monitoring.<\/p>\n\n\n\n
Example architecture:<\/p>\n\n\n\n
Proxmox Host\n\u2502\n\u251c\u2500\u2500 VM 100 \u2014 Docker \/ Traefik \/ Portainer\n\u251c\u2500\u2500 VM 101 \u2014 Video meeting server\n\u2514\u2500\u2500 VM 102 \u2014 Monitoring \/ Uptime Kuma\n<\/code><\/pre>\n\n\n\nThis separation is useful because the monitoring VM can watch the other VMs without mixing workloads.<\/p>\n\n\n\n
The monitoring VM stays lightweight and focused.<\/p>\n\n\n\n
It does not run video meetings.
It does not run the reverse proxy.
It does not run the main application stack.
It only monitors.<\/p>\n\n\n\n
\n\n\n\nMy Monitoring VM Design<\/h2>\n\n\n\n
For the monitoring VM, I used a small Debian server.<\/p>\n\n\n\n
Example VM specification:<\/p>\n\n\n\n
OS: Debian 12\nCPU: 2 vCPU\nRAM: 4 GB\nDisk: 80 GB\nNetwork: private bridge\nAccess: private only\nMonitoring app: Uptime Kuma\nRuntime: Docker + Docker Compose\n<\/code><\/pre>\n\n\n\nThis is more than enough for a small monitoring dashboard.<\/p>\n\n\n\n
The goal was not to build a heavy server. The goal was to build a reliable control point that can monitor other services and later help with backup checks.<\/p>\n\n\n\n
\n\n\n\nWhy I Kept Uptime Kuma Private<\/h2>\n\n\n\n
One important decision: I did not<\/strong> expose Uptime Kuma publicly at first.<\/p>\n\n\n\nThe dashboard was only reachable through the private server network.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
Uptime Kuma private address:\nhttp://10.0.10.20:3001\n<\/code><\/pre>\n\n\n\nFrom my computer, I accessed it through an SSH tunnel:<\/p>\n\n\n\n
ssh -N -L 13001:10.0.10.20:3001 user@proxmox.example.com\n<\/code><\/pre>\n\n\n\nThen I opened:<\/p>\n\n\n\n
http://localhost:13001\n<\/code><\/pre>\n\n\n\nThis gave me secure access without creating a public dashboard.<\/p>\n\n\n\n
That is the safest starting point.<\/p>\n\n\n\n
Later, it is possible to expose the dashboard through a protected subdomain like:<\/p>\n\n\n\n
monitor.example.com\n<\/code><\/pre>\n\n\n\nBut I recommend doing that only after adding strong protection, such as:<\/p>\n\n\n\n
Reverse proxy basic authentication\nUptime Kuma login\nVPN or IP allowlist\nStrong passwords\nHTTPS\n<\/code><\/pre>\n\n\n\nA monitoring dashboard tells a lot about your infrastructure. Do not expose it casually.<\/p>\n\n\n\n
\n\n\n\nInstalling Uptime Kuma with Docker Compose<\/h2>\n\n\n\n
The basic Docker Compose idea is simple.<\/p>\n\n\n\n
Example folder:<\/p>\n\n\n\n
\/opt\/monitoring\/uptime-kuma\n<\/code><\/pre>\n\n\n\nExample compose.yaml<\/code>:<\/p>\n\n\n\nservices:\n uptime-kuma:\n image: louislam\/uptime-kuma:2\n container_name: uptime-kuma\n restart: unless-stopped\n volumes:\n - .\/data:\/app\/data\n ports:\n - \"10.0.10.20:3001:3001\"\n<\/code><\/pre>\n\n\n\nA few important details:<\/p>\n\n\n\n
The data folder is very important:<\/p>\n\n\n\n
.\/data:\/app\/data\n<\/code><\/pre>\n\n\n\nThat folder stores:<\/p>\n\n\n\n
Dashboard users\nMonitor settings\nHistory\nNotification settings\nDatabase files\n<\/code><\/pre>\n\n\n\nDo not delete it unless you intentionally want to reset Uptime Kuma.<\/p>\n\n\n\n
Start it with:<\/p>\n\n\n\n
docker compose up -d\n<\/code><\/pre>\n\n\n\nCheck it with:<\/p>\n\n\n\n
docker compose ps\n<\/code><\/pre>\n\n\n\nA healthy container should show something like:<\/p>\n\n\n\n
uptime-kuma Up healthy\n<\/code><\/pre>\n\n\n\n
\n\n\n\nThe First Setup Page<\/h2>\n\n\n\n
After the container starts, open the dashboard through your private access method.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
http://localhost:13001\n<\/code><\/pre>\n\n\n\nOn first launch, Uptime Kuma asks you to create an admin account.<\/p>\n\n\n\n
Use a strong password and save it safely.<\/p>\n\n\n\n
For a simple self-hosted setup, the default SQLite option is fine.<\/p>\n\n\n\n
\n\n\n\nThe First Monitors I Added<\/h2>\n\n\n\n
After the dashboard was ready, I added basic monitors.<\/p>\n\n\n\n
Example monitors:<\/p>\n\n\n\n
Main Public Website\nInternal Application Web Check\nReverse Proxy Auth Check\nAdmin Dashboard Auth Check\nVM 100 Ping\nVM 101 Ping\nVM 102 Ping\nMonitoring Self Check\nPrivate Gateway Ping\n<\/code><\/pre>\n\n\n\nFor HTTP checks, Uptime Kuma can verify status codes.<\/p>\n\n\n\n
For example, a normal public website should return:<\/p>\n\n\n\n
200 OK\n<\/code><\/pre>\n\n\n\nBut a protected dashboard may return:<\/p>\n\n\n\n
401 Unauthorized\n<\/code><\/pre>\n\n\n\nThat can actually be a good result.<\/p>\n\n\n\n
If a dashboard is supposed to be protected by basic authentication, then 401 Unauthorized<\/code> means:<\/p>\n\n\n\nThe service is reachable\nThe protection layer is working\nThe dashboard is not openly exposed\n<\/code><\/pre>\n\n\n\nSo in Uptime Kuma, I created some monitors where the accepted status code is:<\/p>\n\n\n\n
401\n<\/code><\/pre>\n\n\n\nThis is useful for checking protected admin tools.<\/p>\n\n\n\n
\n\n\n\nThe Hairpin NAT Problem<\/h2>\n\n\n\n
One issue I ran into was internal monitoring of public domains.<\/p>\n\n\n\n
From outside the server, a domain like this may work:<\/p>\n\n\n\n
https://app.example.com\n<\/code><\/pre>\n\n\n\nBut from inside a private VM, the same domain may resolve to the public server IP and fail.<\/p>\n\n\n\n
This is often because of hairpin NAT or loopback NAT.<\/p>\n\n\n\n
In simple terms:<\/p>\n\n\n\n
Private VM\n\u2192 public domain\n\u2192 public IP of same server\n\u2192 tries to loop back inside\n\u2192 connection fails\n<\/code><\/pre>\n\n\n\nThe service was not actually down. The private monitoring VM just could not reach it using the public path.<\/p>\n\n\n\n
To solve this, I forced the Uptime Kuma container to resolve certain public service domains to the private reverse proxy IP.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
extra_hosts:\n - \"app.example.com:10.0.10.10\"\n - \"dashboard.example.com:10.0.10.10\"\n - \"admin.example.com:10.0.10.10\"\n<\/code><\/pre>\n\n\n\nAfter recreating the container, Uptime Kuma could monitor those domains through the internal network while still using the real HTTPS hostname.<\/p>\n\n\n\n
This is a very useful trick for private monitoring behind a reverse proxy.<\/p>\n\n\n\n
\n\n\n\nExample Final Compose File<\/h2>\n\n\n\n
Here is a generalized example:<\/p>\n\n\n\n
services:\n uptime-kuma:\n image: louislam\/uptime-kuma:2\n container_name: uptime-kuma\n restart: unless-stopped\n volumes:\n - .\/data:\/app\/data\n ports:\n - \"10.0.10.20:3001:3001\"\n extra_hosts:\n - \"app.example.com:10.0.10.10\"\n - \"reverse-proxy.example.com:10.0.10.10\"\n - \"dashboard.example.com:10.0.10.10\"\n<\/code><\/pre>\n\n\n\nIn this example:<\/p>\n\n\n\n
10.0.10.20 = monitoring VM\n10.0.10.10 = reverse proxy VM\n<\/code><\/pre>\n\n\n\nUse your own private IPs and domains.<\/p>\n\n\n\n
Do not publish private details in public tutorials.<\/p>\n\n\n\n
\n\n\n\nUseful Maintenance Commands<\/h2>\n\n\n\n
Check the container:<\/p>\n\n\n\n
cd \/opt\/monitoring\/uptime-kuma\ndocker compose ps\n<\/code><\/pre>\n\n\n\nView logs:<\/p>\n\n\n\n
docker logs --tail 50 uptime-kuma\n<\/code><\/pre>\n\n\n\nRestart Uptime Kuma:<\/p>\n\n\n\n
cd \/opt\/monitoring\/uptime-kuma\ndocker compose restart\n<\/code><\/pre>\n\n\n\nUpdate Uptime Kuma:<\/p>\n\n\n\n
cd \/opt\/monitoring\/uptime-kuma\ndocker compose pull\ndocker compose up -d\n<\/code><\/pre>\n\n\n\nTest the private web port:<\/p>\n\n\n\n
curl -I http:\/\/10.0.10.20:3001\n<\/code><\/pre>\n\n\n\nTest a monitored domain from inside the container:<\/p>\n\n\n\n
docker exec uptime-kuma curl -Ik https:\/\/app.example.com\n<\/code><\/pre>\n\n\n\nCheck whether a domain resolves correctly inside the container:<\/p>\n\n\n\n
docker exec uptime-kuma getent hosts app.example.com\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy I Took Snapshots During the Build<\/h2>\n\n\n\n
Before major changes, I took Proxmox snapshots.<\/p>\n\n\n\n
Example snapshot stages:<\/p>\n\n\n\n
clean-debian-base\ndocker-installed-before-monitoring\nuptime-kuma-working-private\n<\/code><\/pre>\n\n\n\nThis made the build safer.<\/p>\n\n\n\n
If something broke, I could roll back to a known good point.<\/p>\n\n\n\n
However, snapshots are not the same as real backups.<\/p>\n\n\n\n
A snapshot stored on the same server is useful for rollback, but it does not protect you if the whole server or storage pool fails.<\/p>\n\n\n\n
For real disaster recovery, you still need off-server backups.<\/p>\n\n\n\n
A better future backup plan would include:<\/p>\n\n\n\n
Proxmox VM backups\nOff-server storage\nBackup verification\nBackup pruning\nBackup success\/failure monitoring\nAlert notifications\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat Uptime Kuma Does Not Replace<\/h2>\n\n\n\n
Uptime Kuma is excellent for availability monitoring, but it does not replace everything.<\/p>\n\n\n\n
It does not replace:<\/p>\n\n\n\n
Full server backups\nSecurity hardening\nFirewall rules\nLog management\nIntrusion detection\nDisaster recovery planning\nApplication-level debugging\n<\/code><\/pre>\n\n\n\nIt tells you when something is down or unhealthy.<\/p>\n\n\n\n
Then you still need good maintenance practices to fix the problem.<\/p>\n\n\n\n
\n\n\n\nShould Uptime Kuma Be Public?<\/h2>\n\n\n\n
My recommendation: start private.<\/p>\n\n\n\n
Use SSH tunnel or VPN first.<\/p>\n\n\n\n
Expose it publicly only if you really need it, and only with multiple protection layers.<\/p>\n\n\n\n
A safe future setup might look like:<\/p>\n\n\n\n
https://monitor.example.com\n<\/code><\/pre>\n\n\n\nProtected by:<\/p>\n\n\n\n
HTTPS\nReverse proxy authentication\nUptime Kuma login\nVPN or IP allowlist\nStrong admin password\n<\/code><\/pre>\n\n\n\nFor public visitors, use a separate public status page instead of exposing the admin dashboard.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
https://status.example.com\n<\/code><\/pre>\n\n\n\nThat page can show limited public information without exposing the full monitoring admin panel.<\/p>\n\n\n\n
\n\n\n\nBest Services to Monitor First<\/h2>\n\n\n\n
Start simple.<\/p>\n\n\n\n
Good first monitors:<\/p>\n\n\n\n
Main website HTTP check\nInternal app HTTP check\nReverse proxy dashboard auth check\nAdmin dashboard auth check\nMain VM ping checks\nMonitoring server self-check\nPrivate gateway ping\nSSL certificate check\n<\/code><\/pre>\n\n\n\nLater, add more advanced checks:<\/p>\n\n\n\n
Backup success\/failure check\nDisk usage check\nDatabase health check\nDocker container check\nVideo service internal check\nTURN\/STUN service check\nAPI endpoint check\nNotification delivery test\n<\/code><\/pre>\n\n\n\nDo not try to monitor everything on day one.<\/p>\n\n\n\n
Build a clean foundation first.<\/p>\n\n\n\n
\n\n\n\nLessons Learned<\/h2>\n\n\n\n
The biggest lessons from this build:<\/p>\n\n\n\n
Keep monitoring separate from main services.\nDo not install monitoring on the Proxmox host.\nKeep the dashboard private at first.\nUse Docker Compose for clean deployment.\nTake snapshots before major changes.\nDo not confuse snapshots with real backups.\nUse 401 Unauthorized as a healthy result for protected dashboards.\nWatch out for hairpin NAT when monitoring public domains from inside a private network.\nAdd alerts after the basic dashboard is stable.\n<\/code><\/pre>\n\n\n\n
\n\n\n\nFinal Thoughts<\/h2>\n\n\n\n
Uptime Kuma is one of the easiest and most useful tools to add to a self-hosted infrastructure.<\/p>\n\n\n\n
It gives you visibility.<\/p>\n\n\n\n
Instead of guessing whether your services are working, you can see the status in one place.<\/p>\n\n\n\n
For my setup, the best approach was:<\/p>\n\n\n\n
Dedicated monitoring VM\nDebian server\nDocker Compose\nPrivate Uptime Kuma dashboard\nSSH tunnel access\nInternal service checks\nProtected dashboard checks\nSnapshots before major changes\n<\/code><\/pre>\n\n\n\nThe next important step is alerting.<\/p>\n\n\n\n
A dashboard is helpful, but alerts are what tell you something is wrong when you are not looking.<\/p>\n\n\n\n
For production, I would add:<\/p>\n\n\n\n
Telegram alerts\nEmail alerts\nBackup monitoring\nDisk usage checks\nOff-server backup verification\n<\/code><\/pre>\n\n\n\nMonitoring is not the end of server maintenance, but it is one of the best foundations you can build early.<\/p>\n\n\n\n
\n\n\n\nFAQ<\/h1>\n\n\n\nWhat is Uptime Kuma used for?<\/h2>\n\n\n\n
Uptime Kuma is used to monitor websites, servers, APIs, ports, and internal services. It shows whether each service is up or down and can send alerts when something fails.<\/p>\n\n\n\n
Is Uptime Kuma free?<\/h2>\n\n\n\n
Yes. Uptime Kuma is an open-source self-hosted monitoring tool.<\/p>\n\n\n\n
Can Uptime Kuma monitor private services?<\/h2>\n\n\n\n
Yes. If Uptime Kuma runs inside your private network, it can monitor private IP addresses, internal services, and private dashboards.<\/p>\n\n\n\n
Should I expose Uptime Kuma to the internet?<\/h2>\n\n\n\n
It is better to keep it private at first. Use an SSH tunnel or VPN. If you expose it later, protect it with HTTPS, reverse proxy authentication, Uptime Kuma login, and preferably VPN or IP allowlisting.<\/p>\n\n\n\n
Can Uptime Kuma monitor Proxmox?<\/h2>\n\n\n\n
Uptime Kuma can monitor Proxmox-related services indirectly through ping checks, HTTPS checks, port checks, and custom scripts. It is not a full Proxmox management replacement.<\/p>\n\n\n\n
Why does my public domain fail from inside my server?<\/h2>\n\n\n\n
This can happen because of hairpin NAT or loopback NAT. The internal VM resolves the public domain to the public IP, then fails to loop back into the same server. One solution is to use internal DNS or Docker extra_hosts<\/code> to point that domain to the private reverse proxy IP.<\/p>\n\n\n\nIs a Proxmox snapshot a backup?<\/h2>\n\n\n\n
No. A snapshot is a local rollback point. A real backup should be copied off-server to separate storage.<\/p>\n\n\n\n
What should I monitor first?<\/h2>\n\n\n\n
Start with your main website, reverse proxy, key internal services, VM ping checks, the monitoring server itself, and protected dashboard checks.<\/p>\n\n\n\n
\n\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
When you start self-hosting more than one service, monitoring becomes very important. At first, it is…<\/p>\n","protected":false},"author":1,"featured_media":3310,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_blocks_custom_css":"","_kad_blocks_head_custom_js":"","_kad_blocks_body_custom_js":"","_kad_blocks_footer_custom_js":"","_kadence_starter_templates_imported_post":false,"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"above","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[31,18,32,30],"tags":[],"class_list":["post-3307","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-linux-server","category-proxmox","category-server"],"taxonomy_info":{"category":[{"value":31,"label":"Linux"},{"value":18,"label":"linux server"},{"value":32,"label":"proxmox"},{"value":30,"label":"Server"}]},"featured_image_src_large":["https:\/\/muhammadsoliman.com\/wp-content\/uploads\/2026\/06\/ChatGPT-Image-Jun-7-2026-01_39_50-AM-1024x768.png",1024,768,true],"author_info":{"display_name":"Muhammad Soliman","author_link":"https:\/\/muhammadsoliman.com\/author\/muhmmad-soliman\/"},"comment_info":0,"category_info":[{"term_id":31,"name":"Linux","slug":"linux","term_group":0,"term_taxonomy_id":31,"taxonomy":"category","description":"","parent":0,"count":3,"filter":"raw","cat_ID":31,"category_count":3,"category_description":"","cat_name":"Linux","category_nicename":"linux","category_parent":0},{"term_id":18,"name":"linux server","slug":"linux-server","term_group":0,"term_taxonomy_id":18,"taxonomy":"category","description":"","parent":0,"count":3,"filter":"raw","cat_ID":18,"category_count":3,"category_description":"","cat_name":"linux server","category_nicename":"linux-server","category_parent":0},{"term_id":32,"name":"proxmox","slug":"proxmox","term_group":0,"term_taxonomy_id":32,"taxonomy":"category","description":"","parent":0,"count":2,"filter":"raw","cat_ID":32,"category_count":2,"category_description":"","cat_name":"proxmox","category_nicename":"proxmox","category_parent":0},{"term_id":30,"name":"Server","slug":"server","term_group":0,"term_taxonomy_id":30,"taxonomy":"category","description":"","parent":0,"count":3,"filter":"raw","cat_ID":30,"category_count":3,"category_description":"","cat_name":"Server","category_nicename":"server","category_parent":0}],"tag_info":false,"_links":{"self":[{"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/posts\/3307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/comments?post=3307"}],"version-history":[{"count":4,"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/posts\/3307\/revisions"}],"predecessor-version":[{"id":3312,"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/posts\/3307\/revisions\/3312"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/media\/3310"}],"wp:attachment":[{"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/media?parent=3307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/categories?post=3307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/muhammadsoliman.com\/index.php\/wp-json\/wp\/v2\/tags?post=3307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}