📊 Uptime Kuma - Monitor Everything [Part 10 of 10]

IT & Systems
, , , ,
1

:bar_chart: Uptime Kuma - Monitor Everything [Part 10 of 10]

Keep track of your services with beautiful uptime monitoring

:bell::chart_increasing::white_check_mark::police_car_light:

This is it - the final part of our HomeLab series!

You’ve built an amazing homelab with multiple services. But how do you know if they’re all running? When something goes down, how quickly do you find out?

Uptime Kuma is a self-hosted monitoring tool that watches your services 24/7 and alerts you when something breaks.

Features:

  • Monitor websites, APIs, ports, and more

  • Beautiful, modern dashboard

  • Real-time status updates

  • 90+ notification options

  • Public status pages

  • Uptime statistics and graphs

  • Certificate expiry monitoring

  • Ping and TCP monitoring

  • Docker container monitoring

Let’s set it up and complete your HomeLab!

:brain: What is Uptime Kuma?

Uptime Kuma is a self-hosted monitoring tool (like Uptime Robot, but better).

What it monitors:

  • HTTP/HTTPS - Websites and web services

  • TCP Ports - Database servers, SSH, custom services

  • Ping - Network connectivity

  • DNS - Domain resolution

  • Docker Containers - Container health

  • And much more…

Why use it?

  • Know when things break - Get notified immediately

  • Track uptime - See historical performance

  • Public status pages - Share status with users

  • Free and private - No monthly fees, no data sharing

  • Beautiful interface - Actually enjoyable to use

:clipboard: What You’ll Need

Prerequisites

  • :white_check_mark: Docker and Portainer running (Part 4)

  • :white_check_mark: Nginx Proxy Manager configured (Part 5)

  • :white_check_mark: Services to monitor (Parts 6-9)

  • :white_check_mark: At least 1GB RAM

Ports Required

  • Port 3001 - Uptime Kuma web interface

:rocket: Installing Uptime Kuma

Uptime Kuma is a single container with a built-in SQLite database.

Step 1: Create Data Directory

On your Ubuntu server (via SSH):


# Create directory for Uptime Kuma data

sudo mkdir -p /mnt/storage/docker/uptime-kuma

# Set ownership (container runs as user 1000)

sudo chown -R 1000:1000 /mnt/storage/docker/uptime-kuma

Step 2: Deploy via Portainer

Login to Portainer:


https://portainer.homelab.example.com

Create new stack:

  1. Click Stacks in left sidebar

  2. Click + Add stack

  3. Name: uptime-kuma

  4. Build method: Web editor

Paste this compose configuration:


version: '3.8'

services:

uptime-kuma:

container_name: uptime-kuma

image: louislam/uptime-kuma:2

environment:

TZ: America/New_York # Change to your timezone

UMASK: '0022'

volumes:

- /mnt/storage/docker/uptime-kuma:/app/data

ports:

- '3001:3001'

restart: unless-stopped

networks:

- portainer-network

healthcheck:

test: ["CMD", "curl", "-f", "http://localhost:3001"]

interval: 30s

retries: 3

start_period: 10s

timeout: 5s

networks:

portainer-network:

external: true

Note about timezone:

  • Find your timezone: TZ Database Timezones

  • Examples: America/New_York, America/Los_Angeles, Europe/London, Asia/Tokyo

Step 3: Deploy the Stack

Deploy:

  • Scroll down

  • Click Deploy the stack

  • Wait 1-2 minutes for deployment

Verify deployment:

  • Go to Containers in Portainer

  • Confirm container is running:

  • uptime-kuma

Step 4: Configure Firewall

On your Ubuntu server (via SSH):


# Allow Uptime Kuma from LAN

sudo ufw allow from 192.168.1.0/24 to any port 3001 proto tcp comment 'Uptime Kuma from LAN'

# Check firewall status

sudo ufw status numbered

Note: Replace 192.168.1.0/24 with your network range.

Step 5: Allow Docker Container Access

Important: Uptime Kuma runs in Docker and needs to access services on your host. First, find your Docker network range:


# Find your Docker network subnet

docker network inspect bridge | grep Subnet

# Output will show something like: "Subnet": "172.17.0.0/16" or "172.18.0.0/16"

Then add firewall rules using YOUR Docker subnet:


# Replace 172.18.0.0/16 with YOUR Docker subnet from above!

# Allow Docker containers to access service ports

sudo ufw allow from 172.18.0.0/16 to any port 80 proto tcp comment 'Docker to HTTP'

sudo ufw allow from 172.18.0.0/16 to any port 81 proto tcp comment 'Docker to NPM'

sudo ufw allow from 172.18.0.0/16 to any port 443 proto tcp comment 'Docker to HTTPS'

sudo ufw allow from 172.18.0.0/16 to any port 2283 proto tcp comment 'Docker to Immich'

sudo ufw allow from 172.18.0.0/16 to any port 3000 proto tcp comment 'Docker to Wiki.js'

sudo ufw allow from 172.18.0.0/16 to any port 8080 proto tcp comment 'Docker to Discourse HTTP'

sudo ufw allow from 172.18.0.0/16 to any port 8443 proto tcp comment 'Docker to Discourse HTTPS'

sudo ufw allow from 172.18.0.0/16 to any port 8888 proto tcp comment 'Docker to OpenSpeedTest'

sudo ufw allow from 172.18.0.0/16 to any port 9443 proto tcp comment 'Docker to Portainer'

# Reload firewall

sudo ufw reload

Why? Docker containers use a different network than your LAN. Without these rules, monitors will timeout.

Note: Common Docker subnets are 172.17.0.0/16 or 172.18.0.0/16, but yours may differ.

:globe_with_meridians: Setting Up Proxy with NPM

Now let’s add Uptime Kuma to Nginx Proxy Manager.

Step 1: Create SSL Certificate

Login to NPM:


https://npm.homelab.example.com

Create certificate:

  1. Go to SSL Certificates

  2. Click Add SSL Certificate → Let’s Encrypt

  3. Domain Names: uptime.homelab.example.com

  4. Use a DNS Challenge: :white_check_mark: Enable (if using DNS challenge)

  5. Email Address: Your email for Let’s Encrypt notifications

  6. Agree to Terms: :white_check_mark: Check

  7. Click Save

  8. Wait for certificate issuance (1-2 minutes)

Step 2: Create Proxy Host

In NPM:

  1. Go to Hosts → Proxy Hosts

  2. Click Add Proxy Host

Details Tab:

  • Domain Names: uptime.homelab.example.com

  • Scheme: http

  • Forward Hostname/IP: uptime-kuma (container name)

  • Forward Port: 3001

  • Cache Assets: :white_check_mark: Enable

  • Block Common Exploits: :white_check_mark: Enable

  • Websockets Support: :white_check_mark: Enable (REQUIRED for real-time updates!)

SSL Tab:

  • SSL Certificate: Select your certificate

  • Force SSL: :white_check_mark: Enable

  • HTTP/2 Support: :white_check_mark: Enable

  • HSTS Enabled: :white_large_square: Leave unchecked

Click: Save

Step 3: Test Access

Open your browser:


https://uptime.homelab.example.com

You should see the Uptime Kuma setup screen!

:artist_palette: First-Time Setup

Create Admin Account

On first access:

  1. Username: Choose a username

  2. Password: Choose a strong password

  3. Repeat Password: Confirm password

  4. Click Create

Need a strong password?

You’ll be taken to the dashboard!

:bar_chart: Adding Monitors

Now let’s monitor all your services!

Understanding Monitor URLs

For services on portainer-network (use container names):

  • Nginx Proxy Manager

  • Immich

  • Wiki.js

  • OpenSpeedTest

For services NOT on portainer-network (use host IP):

  • Portainer

  • Discourse

Monitor 1: Nginx Proxy Manager

Click: Add New Monitor

Configuration:

  • Monitor Type: HTTP(s)

  • Friendly Name: Nginx Proxy Manager

  • URL: http://nginx-proxy-manager:81

  • Heartbeat Interval: 60 seconds

  • Retries: 3

  • Heartbeat Retry Interval: 60 seconds

  • Accepted Status Codes: 200-299,300-399

Click: Save

Monitor 2: Portainer

Click: Add New Monitor

Configuration:

  • Monitor Type: HTTP(s)

  • Friendly Name: Portainer

  • URL: https://192.168.1.100:9443

  • Heartbeat Interval: 60 seconds

  • Retries: 3

  • Accepted Status Codes: 200-299,300-399,400-499

  • Advanced Settings:

  • Ignore TLS/SSL error: :white_check_mark: Enable (self-signed certificate)

Click: Save

Monitor 3: Immich

Click: Add New Monitor

Configuration:

  • Monitor Type: HTTP(s)

  • Friendly Name: Immich

  • URL: http://immich_server:2283

  • Heartbeat Interval: 60 seconds

  • Retries: 3

  • Accepted Status Codes: 200-299

Click: Save

Monitor 4: Discourse

Click: Add New Monitor

Configuration:

  • Monitor Type: HTTP(s)

  • Friendly Name: Discourse

  • URL: http://192.168.1.100:8080

  • Heartbeat Interval: 60 seconds

  • Retries: 3

  • Accepted Status Codes: 200-299

Click: Save

Monitor 5: Wiki.js

Click: Add New Monitor

Configuration:

  • Monitor Type: HTTP(s)

  • Friendly Name: Wiki.js

  • URL: http://wikijs:3000

  • Heartbeat Interval: 60 seconds

  • Retries: 3

  • Accepted Status Codes: 200-299

Click: Save

Monitor 6: OpenSpeedTest

Click: Add New Monitor

Configuration:

  • Monitor Type: HTTP(s)

  • Friendly Name: OpenSpeedTest

  • URL: http://openspeedtest:3000

  • Heartbeat Interval: 60 seconds

  • Retries: 3

  • Accepted Status Codes: 200-299

Click: Save

:bell: Setting Up Notifications

Get alerted when services go down!

Step 1: Add Notification Method

Click: Settings (gear icon) → Notifications

Click: Setup Notification

Choose your notification type:

Popular options:

  • Email (SMTP) - Requires SMTP server (like Brevo from Part 7)

  • Discord - Create webhook in Discord server

  • Telegram - Use Telegram bot

  • Slack - Use Slack webhook

  • Pushover - Mobile push notifications

  • 90+ other options!

Example: Email Notifications (SMTP)

If you set up Brevo for Discourse:

  1. Notification Type: SMTP (Email)

  2. Friendly Name: Email Alerts

  3. SMTP Host: smtp-relay.brevo.com

  4. SMTP Port: 587

  5. Security: TLS

  6. Username: Your Brevo email

  7. Password: Your Brevo SMTP key

  8. From Email: Your verified sender email

  9. To Email: Your email address

  10. Click: Test (verify it works)

  11. Click: Save

Step 2: Apply to Monitors

For each monitor:

  1. Click the monitor name

  2. Click Edit

  3. Scroll to Notifications

  4. Select your notification method

  5. Click: Save

Now you’ll get alerts when services go down! :bell:

:chart_increasing: Using Uptime Kuma

Dashboard View

Your dashboard shows:

  • :white_check_mark: Green - Service is up

  • :cross_mark: Red - Service is down

  • :pause_button: Gray - Monitor paused

  • Response time - How fast service responds

  • Uptime percentage - 99.9% = very reliable

Viewing History

Click any monitor to see:

  • Uptime graph

  • Response time chart

  • Recent events

  • Certificate expiry (for HTTPS)

  • Average response time

Creating Status Pages

Share uptime publicly:

  1. Click: Status Pages

  2. Click: New Status Page

  3. Configure:

  • Title: Your status page name

  • Slug: URL path (e.g., homelab)

  • Select monitors to display

  1. Click: Save

Share URL: https://uptime.homelab.example.com/status/homelab

:wrench: Maintenance

Check Container Status


# View Uptime Kuma container

docker ps | grep uptime-kuma

# Check logs

docker logs uptime-kuma

# Follow logs in real-time

docker logs -f uptime-kuma

Backup Uptime Kuma


# Backup database and configuration

sudo tar -czf uptime-kuma-backup-$(date +%Y%m%d).tar.gz \

/mnt/storage/docker/uptime-kuma/

# Store backup off-site!

Restore from Backup


# Stop container

docker stop uptime-kuma

# Restore backup

sudo tar -xzf uptime-kuma-backup-YYYYMMDD.tar.gz -C /

# Start container

docker start uptime-kuma

Update Uptime Kuma

Via Portainer:

  1. Go to Stacks → uptime-kuma

  2. Click Editor

  3. Click Update the stack

  4. Select Re-pull image and redeploy

  5. Wait for update to complete

Check for updates monthly - Uptime Kuma is actively developed.

:hammer_and_wrench: Troubleshooting

Dashboard Not Updating in Real-Time

Problem: Dashboard shows old data, doesn’t auto-refresh.

Solution: Enable Websockets in NPM:

  1. Go to NPM → Proxy Hosts

  2. Edit uptime.homelab.example.com

  3. Details tab → Websockets Support: :white_check_mark: Enable

  4. Save and refresh browser

Monitors Showing Down When Services Are Up

Problem: False positives - services are up but monitors say down.

Solutions:

Check accepted status codes:

  • Some services return 301/302 redirects

  • Add 300-399 to accepted codes

Increase retries:

  • Set Retries to 3 or more

  • Prevents false alerts from temporary issues

Check firewall rules:

  • Verify Docker network rules (Step 5 of installation)

  • Test: docker exec uptime-kuma curl http://192.168.1.100:81

Cannot Access Specific Service

Problem: One monitor always times out.

Check:

  1. Service is actually running

  2. Firewall allows Docker network access

  3. Using correct URL (container name vs IP)

  4. Port is correct (internal vs external)

:tada: Congratulations!

You did it! You’ve completed the entire HomeLab series!

What You’ve Built:

  1. :white_check_mark: Physical Server - Custom hardware with RAID storage

  2. :white_check_mark: Docker & Portainer - Container management platform

  3. :white_check_mark: Nginx Proxy Manager - Reverse proxy with SSL

  4. :white_check_mark: Immich - Private photo backup

  5. :white_check_mark: Discourse - Community forum

  6. :white_check_mark: Wiki.js - Knowledge base

  7. :white_check_mark: OpenSpeedTest - Network speed testing

  8. :white_check_mark: Uptime Kuma - Service monitoring

You now have a production-grade homelab! :rocket:

:crystal_ball: What’s Next?

Expand Your HomeLab:

More Services:

  • Nextcloud - File sync and sharing

  • Plex/Jellyfin - Media server

  • Home Assistant - Smart home automation

  • Vaultwarden - Password manager

  • Paperless-ngx - Document management

  • Gitea - Self-hosted Git

Advanced Topics:

  • Backups - Automated backup solutions

  • VPN - Remote access via WireGuard

  • Monitoring - Prometheus + Grafana

  • Security - Fail2ban, Crowdsec

  • High Availability - Multiple servers

:brain: TL;DR

  • Uptime Kuma monitors your services 24/7

  • Features: HTTP/HTTPS monitoring, notifications, status pages

  • Installation: Single container with SQLite database

  • Setup: Create monitors for all services

  • Notifications: 90+ options including email, Discord, Telegram

  • Dashboard: Real-time status with uptime graphs

  • You’ve completed the entire HomeLab series! :tada:

:speech_balloon: Final Thoughts

Thank you for following this series!

Building a homelab is a journey. You’ve learned:

  • Server hardware and assembly

  • RAID storage configuration

  • Docker containerization

  • Reverse proxy and SSL

  • Self-hosted applications

  • Network monitoring

Keep learning, keep building, and enjoy your homelab!

What will you add to your homelab next?

What was your favorite part of this series?

Any questions or feedback?

Drop a comment below!

Navigation: ← Part 9