Uptime Kuma Advanced: Notifications and Status Pages

Uptime Kuma is a beautiful, self-hosted monitoring tool that checks if your services are up and running. This comprehensive guide covers advanced configurations, notification integrations, status pages, and best practices for production homelab monitoring.

What You’ll Learn

Advanced monitoring configurations (HTTP, TCP, DNS, Ping, Docker, Kubernetes)
Setting up 20+ notification channels (Discord, Slack, Telegram, Gotify, Pushover)
Creating public and private status pages
API integration and automation
Multi-user management and access control
Backup strategies and high availability
Performance tuning for low-resource systems
Integration with other monitoring tools

Prerequisites

Docker and Docker Compose installed
Basic understanding of HTTP protocols
Services to monitor
Notification platform accounts (Discord, Slack, etc.)

Why Uptime Kuma?

Advantages Over Alternatives

vs UptimeRobot:

Self-hosted (full control over data)
No monitor limits
Beautiful, modern UI
More notification channels
Status page included

vs Pingdom:

Free and open source
No subscription costs
Unlimited monitors
Docker container support
Flexible notification routing

vs Healthchecks.io:

Easier setup for HTTP monitoring
Built-in status pages
Visual dashboard
More notification providers
Better for service availability monitoring

Key Features

30+ notification channels: Discord, Slack, Telegram, email, SMS, and more
Beautiful UI: Modern, responsive interface
Status pages: Public and private status pages
Multi-protocol: HTTP, HTTPS, TCP, Ping, DNS, Docker, Kubernetes
Flexible monitoring: Keywords, status codes, response times
Certificate monitoring: SSL expiry warnings
Multi-user: Team collaboration with role-based access
Mobile-friendly: Works great on phones and tablets
Low resource usage: Runs on Raspberry Pi

Complete Docker Compose Setup

Create a production-ready Uptime Kuma installation with reverse proxy support.

docker-compose.yml

version: '3.8'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma-data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock:ro  # For Docker monitoring
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    networks:
      - monitoring
    healthcheck:
      test: ["CMD", "node", "/app/extra/healthcheck.js"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s

  # Optional: Caddy reverse proxy with automatic HTTPS
  caddy:
    image: caddy:latest
    container_name: caddy-uptime-kuma
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy-data:/data
      - caddy-config:/config
    networks:
      - monitoring
    depends_on:
      - uptime-kuma

volumes:
  uptime-kuma-data:
  caddy-data:
  caddy-config:

networks:
  monitoring:
    driver: bridge

Caddyfile for Reverse Proxy

Create ./Caddyfile:

status.yourdomain.com {
    reverse_proxy uptime-kuma:3001

    # Security headers
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "no-referrer-when-downgrade"
    }

    # Rate limiting (optional)
    rate_limit {
        zone dynamic {
            key {remote_host}
            events 30
            window 1m
        }
    }
}

Deploy the stack:

docker-compose up -d
docker logs -f uptime-kuma

Access Uptime Kuma at http://YOUR-SERVER-IP:3001 or https://status.yourdomain.com.

Initial Setup and Configuration

Navigate to Uptime Kuma URL
Create admin account:
- Username: admin
- Password: Strong password with 12+ characters
Save credentials securely

Dashboard Overview

The main dashboard shows:

Monitor list: All configured monitors with status
Status: Up (green), Down (red), Pending (orange)
Uptime percentage: 24h, 7d, 30d, 90d
Response time: Average latency
Certificate expiry: SSL certificate days remaining

General Settings

Navigate to Settings → General:

Language: English
Theme: Dark (or Auto)
Search Engine Visibility: Disabled (for private instances)
Primary Base URL: https://status.yourdomain.com
Server Timezone: Your timezone
Enable 2FA: Recommended for security

Advanced Monitor Types

HTTP/HTTPS Monitoring

Most common monitor type for web services.

Basic HTTP Monitor:

Monitor Type: HTTP(s)
Friendly Name: Personal Website
URL: https://example.com
Heartbeat Interval: 60 seconds
Retries: 2
Heartbeat Retry Interval: 20 seconds
Request Timeout: 48 seconds
Method: GET

Advanced HTTP with Authentication:

Monitor Type: HTTP(s)
Friendly Name: Admin Panel
URL: https://admin.example.com/health
Method: POST
Headers:
  Authorization: Bearer your-api-token
  Content-Type: application/json
Body:
  {
    "check": "health"
  }
Expected Status Codes: 200,201
Keyword (Up): "status":"healthy"
Keyword (Down): "error","maintenance"

API Endpoint Monitoring:

Monitor Type: HTTP(s) - JSON Query
Friendly Name: API Health Check
URL: https://api.example.com/v1/status
JSON Query: $.status
Expected Value: "operational"

TCP Port Monitoring

Check if specific ports are open and responding.

Database Port Check:

Monitor Type: TCP Port
Friendly Name: PostgreSQL Database
Hostname: postgres.local
Port: 5432
Heartbeat Interval: 30 seconds

SSH Server Check:

Monitor Type: TCP Port
Friendly Name: SSH Server
Hostname: YOUR-SERVER-IP
Port: 22
Heartbeat Interval: 60 seconds

Ping/ICMP Monitoring

Check network connectivity to hosts.

Basic Ping Monitor:

Monitor Type: Ping
Friendly Name: Router
Hostname: 192.168.1.1
Heartbeat Interval: 60 seconds
Packet Size: 56 bytes

DNS Monitoring

Verify DNS resolution is working correctly.

DNS Query Monitor:

Monitor Type: DNS
Friendly Name: DNS Resolution
Hostname: example.com
Resolver Server: 1.1.1.1
DNS Record Type: A
Expected IP: 93.184.216.34

Custom DNS Server Check:

Monitor Type: DNS
Friendly Name: Pi-hole DNS
Hostname: github.com
Resolver Server: YOUR-PIHOLE-IP
DNS Record Type: A
Port: 53

Docker Container Monitoring

Monitor Docker containers directly.

Container Health Check:

Monitor Type: Docker Container
Friendly Name: Nginx Container
Container Name/ID: nginx
Docker Daemon: /var/run/docker.sock
Docker Host: (leave empty for local)

Keyword Monitoring

Monitor for specific content on web pages.

Content Verification:

Monitor Type: HTTP(s) - Keyword
Friendly Name: Blog Homepage
URL: https://blog.example.com
Keyword: "Latest Posts"
Invert Keyword: No

Maintenance Detection:

Monitor Type: HTTP(s) - Keyword
Friendly Name: Service Status
URL: https://app.example.com
Keyword: "maintenance mode"
Invert Keyword: Yes (alert if maintenance keyword found)

Certificate Monitoring

Get alerts before SSL certificates expire.

Certificate Expiry Check:

Monitor Type: HTTP(s)
Friendly Name: Website SSL
URL: https://example.com
Ignore TLS/SSL Error: No
Certificate Expiry Notification: Enabled
Days Before Expiry (Warning): 14 days
Days Before Expiry (Critical): 7 days

Notification Channels Setup

Discord Notifications

Perfect for homelab community channels.

Setup Steps:

Create Discord webhook:
- Server Settings → Integrations → Webhooks
- New Webhook → Choose channel → Copy webhook URL
In Uptime Kuma:
- Settings → Notifications → Add Notification
- Notification Type: Discord
- Friendly Name: Discord Homelab
- Discord Webhook URL: https://discord.com/api/webhooks/YOUR-WEBHOOK-ID/YOUR-TOKEN
- Bot Display Name: Uptime Kuma
- Prefix Custom Message: No
- Apply to all monitors: Yes (or select specific)

Custom Discord Message Template:

Notification Type: Discord
Message Format:
  Title: [STATUS] Monitor Name
  Description: Monitor is [UP/DOWN]
  Color: Green for up, Red for down
  Fields:
    - Response Time: XXms
    - Status Code: 200
    - Timestamp: ISO format

Slack Notifications

For team collaboration and alerts.

Setup Steps:

Create Slack app:
- Go to https://api.slack.com/apps
- Create New App → From scratch
- Choose workspace
- Incoming Webhooks → Activate → Add New Webhook
- Select channel → Copy webhook URL
In Uptime Kuma:
- Notification Type: Slack
- Friendly Name: Slack Homelab
- Webhook URL: https://hooks.slack.com/services/YOUR/WEBHOOK/URL
- Username: Uptime Kuma
- Icon Emoji: :robot_face:
- Channel: #monitoring

Advanced Slack Configuration:

Notification Type: Slack
Webhook URL: Your webhook
Message Format:
  Channel Override: #critical-alerts (for important monitors)
  Username: Critical Monitor
  Icon: :rotating_light:
  Mention @channel: For critical alerts only

Telegram Notifications

Excellent for mobile push notifications.

Setup Steps:

Create Telegram bot:

- Message @BotFather on Telegram
- Send: /newbot
- Follow prompts to create bot
- Save Bot Token

Get Chat ID:

- Message your bot
- Visit: https://api.telegram.org/botYOUR-BOT-TOKEN/getUpdates
- Find "chat":{"id":123456789}

In Uptime Kuma:
- Notification Type: Telegram
- Bot Token: Your bot token
- Chat ID: Your chat ID
- Thread ID: (optional, for topic groups)
- Send Silently: No

Telegram Group Notifications:

Notification Type: Telegram
Bot Token: Your bot token
Chat ID: -1001234567890 (group chat ID, starts with -100)
Notification Settings: All events

Email Notifications

SMTP email alerts for traditional notifications.

Gmail SMTP Setup:

Enable 2-factor authentication
Create App Password:
- Google Account → Security → 2-Step Verification
- App passwords → Generate
Configure in Uptime Kuma:

Notification Type: Email (SMTP)
Friendly Name: Gmail Alerts
SMTP Host: smtp.gmail.com
SMTP Port: 587
SMTP Security: TLS
SMTP Username: your-[email protected]
SMTP Password: your-app-password (16 chars)
From Email: your-[email protected]
From Name: Uptime Kuma
To Email: [email protected]
Subject: [Uptime Kuma] {MONITOR_NAME} is {STATUS}

Custom Email Server:

Notification Type: Email (SMTP)
SMTP Host: mail.yourdomain.com
SMTP Port: 465
SMTP Security: SSL/TLS
Authentication: Yes
SMTP Username: [email protected]
SMTP Password: your-password
Custom Message: HTML supported

Gotify Notifications

Self-hosted push notification server.

Gotify Setup:

Deploy Gotify:

gotify:
  image: gotify/server:latest
  ports:
    - "8080:80"
  volumes:
    - gotify-data:/app/data

Create application token in Gotify UI
Configure in Uptime Kuma:

Notification Type: Gotify
Server URL: http://YOUR-SERVER-IP:8080
Application Token: Your token
Priority: 5 (1-10, 10 is highest)

Pushover Notifications

Premium push notifications for iOS and Android.

Setup Steps:

Sign up at https://pushover.net (one-time $5 fee)
Get User Key from dashboard
Create application, get API Token
Configure in Uptime Kuma:

Notification Type: Pushover
User Key: Your user key
Application Token/API Key: Your API token
Device: (optional, specific device)
Message Priority: Normal
Sound: pushover (or other sounds)
Retry: 30 seconds (for emergency priority)
Expire: 3600 seconds (1 hour)

Ntfy Notifications

Simple, lightweight push notifications.

Ntfy Setup:

Use public instance or self-host:

ntfy:
  image: binwiederhier/ntfy:latest
  ports:
    - "8081:80"
  volumes:
    - ntfy-data:/var/cache/ntfy

Configure in Uptime Kuma:

Notification Type: Ntfy
Ntfy Server URL: https://ntfy.sh (or your instance)
Ntfy Topic: homelab-monitoring
Priority: Default
Icon: https://your-domain.com/icon.png

Webhook Notifications

Custom integrations with any service.

Generic Webhook:

Notification Type: Webhook
URL: https://your-webhook-endpoint.com/alert
Method: POST
Content Type: application/json
Headers:
  Authorization: Bearer your-api-token
  X-Custom-Header: value
Body:
  {
    "monitor": "{MONITOR_NAME}",
    "status": "{STATUS}",
    "url": "{MONITOR_URL}",
    "time": "{MONITOR_TIME}",
    "message": "{HEARTBEAT_MESSAGE}"
  }

Home Assistant Integration:

Notification Type: Webhook
URL: http://YOUR-HOME-ASSISTANT:8123/api/webhook/uptime_kuma_alert
Method: POST
Body:
  {
    "monitor": "{MONITOR_NAME}",
    "status": "{STATUS}",
    "timestamp": "{MONITOR_TIME}"
  }

Multiple Notification Channels

Configure different notifications for different monitors.

Strategy 1: Severity-Based Routing

Critical services: Discord + Telegram + Email
Important services: Slack + Telegram
Development services: Discord only

Strategy 2: Time-Based Routing

Business hours: Slack
After hours: Telegram + Pushover
Weekends: Email only

Strategy 3: Team-Based Routing

Infrastructure: Discord #infrastructure
Applications: Slack #app-alerts
Security: Telegram + Email

Status Pages

Create beautiful public or private status pages.

Creating Status Pages

Public Status Page:

Navigate to Status Pages
Click “Add New Status Page”
Configure:

Title: Homelab Services Status
Slug: homelab-status (URL will be /status/homelab-status)
Description: Real-time status of homelab services
Theme: Dark
Published: Yes
Show Tags: Yes
Show Powered By: Yes (optional)
Google Analytics ID: (optional)

Add monitors to page:
- Drag monitors from left panel
- Organize into groups
- Set display order

Private Status Page:

Title: Internal Services
Slug: internal
Published: Yes
Password Protected: Yes
Password: SecurePassword123

Status Page Customization

Custom Domain:

Custom Domain: status.yourdomain.com

Configure DNS:

CNAME status.yourdomain.com → your-uptime-kuma-domain.com

Custom CSS:

Navigate to Status Page Settings → Custom CSS:

/* Custom branding */
.shadow-box {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
}

/* Custom header */
.status-page-title {
    font-family: 'Helvetica Neue', sans-serif;
    font-weight: 700;
}

/* Monitor status colors */
.up {
    background-color: #10b981 !important;
}

.down {
    background-color: #ef4444 !important;
}

/* Hide footer */
.footer {
    display: none;
}

Status Page Groups:

Organize monitors into logical groups:

Group 1: Core Services
  - Website
  - API
  - Database

Group 2: Applications
  - Nextcloud
  - Gitea
  - Jellyfin

Group 3: Infrastructure
  - Router
  - NAS
  - Firewall

Incident Management

Create and manage incidents on status pages.

Creating Incident:

Status Page → Incident
Title: “Database Connectivity Issues”
Content: “We’re experiencing connectivity issues with the database server.”
Status: Investigating / Identified / Monitoring / Resolved
Style: Danger / Warning / Info / Primary

Incident Update:

Add updates as situation evolves:

[10:00 AM] Issue identified - Database server unresponsive
[10:15 AM] Server restart initiated
[10:30 AM] Database back online, monitoring for stability
[11:00 AM] Resolved - All services operating normally

Multi-User Management

Configure team access with role-based permissions.

Creating Users

Settings → Security → Users → Add User:

Username: john.doe
Password: SecurePassword123
Role: Regular User
Disable Auth: No

User Roles

Administrator:

Full access to all features
Can manage users
Can modify all monitors
Can configure notifications

Regular User:

View all monitors
Create/edit own monitors
Cannot manage users
Cannot change global settings

Access Control

Per-Monitor Permissions:

Currently Uptime Kuma shares all monitors with all users. For isolation:

Use separate instances for different teams
Use tags for organization
Use status pages with passwords for limited sharing

API Integration

Automate monitor management with the API.

Enable API Access

Settings → Security → Enable API Keys:

API Key Name: Automation
Key: auto-generated-key-here
Permissions: Read/Write

API Examples

Get All Monitors:

curl -X GET "http://YOUR-SERVER-IP:3001/api/monitors"   -H "Authorization: Bearer your-api-key"

Create Monitor:

curl -X POST "http://YOUR-SERVER-IP:3001/api/monitors"   -H "Authorization: Bearer your-api-key"   -H "Content-Type: application/json"   -d '{
    "type": "http",
    "name": "New Service",
    "url": "https://example.com",
    "interval": 60,
    "maxretries": 2,
    "notificationIDList": [1, 2]
  }'

Pause Monitor:

curl -X POST "http://YOUR-SERVER-IP:3001/api/monitors/123/pause"   -H "Authorization: Bearer your-api-key"

Resume Monitor:

curl -X POST "http://YOUR-SERVER-IP:3001/api/monitors/123/resume"   -H "Authorization: Bearer your-api-key"

Terraform Integration

Manage monitors as infrastructure as code:

resource "uptimekuma_monitor" "website" {
  name     = "Personal Website"
  type     = "http"
  url      = "https://example.com"
  interval = 60

  notifications = [
    uptimekuma_notification.discord.id,
    uptimekuma_notification.slack.id
  ]
}

resource "uptimekuma_notification" "discord" {
  name         = "Discord Alerts"
  type         = "discord"
  webhook_url  = var.discord_webhook_url
}

Backup and Restore

Protect your monitoring configuration.

Manual Backup

Settings → Backup:

Click “Backup”
Download JSON file
Store securely (version control recommended)

Automated Backup Script:

#!/bin/bash

UPTIME_KUMA_CONTAINER="uptime-kuma"
BACKUP_DIR="/backups/uptime-kuma"
DATE=$(date +%Y%m%d-%H%M%S)

# Create backup directory
mkdir -p "$BACKUP_DIR"

# Export data directory
docker cp "$UPTIME_KUMA_CONTAINER:/app/data" "$BACKUP_DIR/data-$DATE"

# Compress backup
tar -czf "$BACKUP_DIR/uptime-kuma-backup-$DATE.tar.gz" -C "$BACKUP_DIR" "data-$DATE"

# Remove uncompressed backup
rm -rf "$BACKUP_DIR/data-$DATE"

# Keep only last 30 days of backups
find "$BACKUP_DIR" -name "uptime-kuma-backup-*.tar.gz" -mtime +30 -delete

echo "Backup completed: uptime-kuma-backup-$DATE.tar.gz"

Automated Backup with Cron:

# Add to crontab
0 2 * * * /usr/local/bin/backup-uptime-kuma.sh

Restore from Backup

# Stop container
docker stop uptime-kuma

# Extract backup
tar -xzf uptime-kuma-backup-20251217.tar.gz

# Restore data
docker cp data-20251217/. uptime-kuma:/app/data

# Start container
docker start uptime-kuma

Version Control Backups

Store backups in Git:

#!/bin/bash

BACKUP_DIR="/backups/uptime-kuma"
cd "$BACKUP_DIR"

# Initialize git repo if needed
if [ ! -d .git ]; then
    git init
    git remote add origin YOUR-GIT-REPO
fi

# Create backup
docker exec uptime-kuma node extra/backup.js

# Commit and push
git add backup.json
git commit -m "Automated backup $(date +%Y-%m-%d)"
git push -u origin main

Performance Optimization

Resource Configuration

For Low-Resource Systems (Raspberry Pi):

uptime-kuma:
  deploy:
    resources:
      limits:
        cpus: '0.5'
        memory: 256M
      reservations:
        cpus: '0.1'
        memory: 128M

Monitor Optimization:

Increase intervals: Use 60s+ for non-critical monitors
Reduce retries: Use 1-2 retries instead of 3
Consolidate checks: Monitor gateway instead of every device
Disable unused features: Turn off certificate checks if not needed

Database Maintenance

Uptime Kuma uses SQLite. Periodic maintenance:

# Enter container
docker exec -it uptime-kuma sh

# Navigate to data directory
cd /app/data

# Backup database
cp kuma.db kuma.db.backup

# Vacuum database to reclaim space
sqlite3 kuma.db "VACUUM;"

# Analyze for query optimization
sqlite3 kuma.db "ANALYZE;"

exit

Data Retention

Configure data retention to limit database growth:

Settings → Data Retention:

Keep heartbeat data for: 180 days
Keep notification logs for: 90 days
Keep event logs for: 30 days

Integration with Other Tools

Grafana Dashboard

Create Grafana dashboard using Uptime Kuma API.

Prometheus Exporter:

Use community exporter: https://github.com/lucasheld/uptime-kuma-exporter

uptime-kuma-exporter:
  image: lucasheld/uptime-kuma-exporter:latest
  environment:
    - UPTIME_KUMA_URL=http://uptime-kuma:3001
    - UPTIME_KUMA_USERNAME=admin
    - UPTIME_KUMA_PASSWORD=your-password
  ports:
    - "9101:9101"

Add to Prometheus:

scrape_configs:
  - job_name: 'uptime-kuma'
    static_configs:
      - targets: ['uptime-kuma-exporter:9101']

Home Assistant Integration

Monitor services and create automations.

Configuration.yaml:

sensor:
  - platform: rest
    name: Uptime Kuma Status
    resource: http://YOUR-SERVER-IP:3001/api/monitors
    headers:
      Authorization: Bearer your-api-key
    value_template: "{{ value_json | length }}"
    json_attributes_path: "$[0]"
    json_attributes:
      - name
      - active
      - type

Automation Example:

automation:
  - alias: "Alert when service down"
    trigger:
      - platform: webhook
        webhook_id: uptime_kuma_alert
    condition:
      - condition: template
        value_template: "{{ trigger.json.status == 'down' }}"
    action:
      - service: notify.mobile_app
        data:
          title: "Service Down"
          message: "{{ trigger.json.monitor }} is down!"

Troubleshooting

Monitor False Positives

Issue: Monitor reports down when service is up

Solutions:

Increase timeout: Some services need more than 48s
Add retries: Set to 2-3 retries with 20s interval
Check keywords: Ensure keyword exists on page
Verify SSL: Disable “Ignore TLS Error” for valid certs
Check DNS: Ensure domain resolves correctly

Notification Not Received

Issue: Alerts not arriving

Solutions:

Test notification: Settings → Notifications → Test
Check webhook URL: Verify webhook is still valid
Review logs: Check Docker logs for errors
Verify network: Ensure outbound connections allowed
Rate limits: Some services rate limit webhooks

High Resource Usage

Issue: Container using too much CPU/RAM

Solutions:

Reduce monitor count: Consolidate monitors
Increase intervals: Use 60s+ instead of 30s
Clean database: Run VACUUM maintenance
Reduce retention: Lower data retention period
Check bad monitors: Disable monitors timing out

Database Corruption

Issue: kuma.db corrupted

Solutions:

# Stop container
docker stop uptime-kuma

# Restore from backup
docker cp backup/kuma.db uptime-kuma:/app/data/kuma.db

# Start container
docker start uptime-kuma

# If no backup, export and reimport
sqlite3 kuma.db ".dump" > backup.sql
rm kuma.db
sqlite3 kuma.db < backup.sql

Best Practices

Monitor Configuration

Meaningful names: Use descriptive, consistent naming
Appropriate intervals: 60s for most, 30s for critical, 300s for low priority
Smart retries: Use 2-3 retries to avoid false positives
Keyword validation: Always verify keywords actually exist
Certificate monitoring: Enable for all HTTPS endpoints

Notification Strategy

Avoid alert fatigue: Don’t send every alert to every channel
Escalation paths: Critical → Immediate, Warning → Delayed
Group by severity: Different channels for different priorities
Test regularly: Verify notifications work before you need them
Document runbooks: Include troubleshooting links in alerts

Security

Strong passwords: 12+ characters, unique
Enable 2FA: For admin accounts
Use reverse proxy: Add rate limiting, SSL, authentication
Regular backups: Automated daily backups
Update regularly: Keep Uptime Kuma up to date
Network isolation: Run in separate network segment
Status page passwords: Protect sensitive status pages

Performance

Optimize intervals: Don’t over-monitor
Database maintenance: Monthly VACUUM operations
Resource limits: Set appropriate Docker resource constraints
Data retention: Keep only necessary historical data
Monitor consolidation: Use parent/gateway checks when possible

Advanced Use Cases

Multi-Region Monitoring

Monitor from multiple geographic locations.

Architecture:

Region 1 (US East) → Uptime Kuma Instance 1
Region 2 (EU West) → Uptime Kuma Instance 2
Region 3 (Asia)    → Uptime Kuma Instance 3
                        ↓
            Aggregated Status Page

Implementation:

Deploy Uptime Kuma in each region
Configure same monitors in all instances
Use Grafana or custom dashboard to aggregate
Alert only when all regions report down

Maintenance Windows

Schedule maintenance to prevent false alerts.

Using Pauses:

# Pause monitor via API
curl -X POST "http://YOUR-SERVER-IP:3001/api/monitors/123/pause"   -H "Authorization: Bearer your-api-key"

# Resume after maintenance
curl -X POST "http://YOUR-SERVER-IP:3001/api/monitors/123/resume"   -H "Authorization: Bearer your-api-key"

Automated Maintenance Script:

#!/bin/bash

# Pause monitors
curl -X POST "http://YOUR-SERVER-IP:3001/api/monitors/pause-all"   -H "Authorization: Bearer your-api-key"

# Perform maintenance
echo "Performing maintenance..."
sleep 3600  # 1 hour maintenance

# Resume monitors
curl -X POST "http://YOUR-SERVER-IP:3001/api/monitors/resume-all"   -H "Authorization: Bearer your-api-key"

SLA Reporting

Calculate and report service level agreements.

Monitor Configuration:

Friendly Name: Production API
URL: https://api.production.com
Uptime Target: 99.9% (Three nines)

Monthly SLA Check:

# Calculate uptime percentage
# 99.9% = max 43 minutes downtime per month
# 99.99% = max 4.3 minutes downtime per month

Reporting:

Export uptime data and create monthly reports showing:

Actual uptime percentage
Total downtime minutes
Number of incidents
Mean time to recovery (MTTR)
SLA compliance status

Next Steps

Explore community plugins and extensions
Set up distributed monitoring across multiple locations
Integrate with incident management platforms
Create custom notification handlers
Build automated remediation scripts
Implement chaos engineering testing

Additional Resources

Uptime Kuma Documentation: https://github.com/louislam/uptime-kuma/wiki
Community Forum: https://www.reddit.com/r/UptimeKuma/
GitHub Issues: https://github.com/louislam/uptime-kuma/issues
Status Page Examples: https://github.com/louislam/uptime-kuma/wiki/Examples

With Uptime Kuma properly configured, you’ll have comprehensive visibility into your homelab service availability, with intelligent alerting that notifies you through your preferred channels without overwhelming you with noise. Start with basic HTTP monitors and gradually expand to cover all critical services.

What You’ll Learn

Prerequisites

Why Uptime Kuma?

Advantages Over Alternatives

Key Features

Complete Docker Compose Setup

docker-compose.yml

Caddyfile for Reverse Proxy

Initial Setup and Configuration

First Login

Dashboard Overview

General Settings

Advanced Monitor Types

HTTP/HTTPS Monitoring

TCP Port Monitoring

Ping/ICMP Monitoring

DNS Monitoring

Docker Container Monitoring

Keyword Monitoring

Certificate Monitoring

Notification Channels Setup

Discord Notifications

Slack Notifications

Telegram Notifications

Email Notifications

Gotify Notifications

Pushover Notifications

Ntfy Notifications

Webhook Notifications

Multiple Notification Channels

Status Pages

Creating Status Pages

Status Page Customization

Incident Management

Multi-User Management

Creating Users

User Roles

Access Control

API Integration

Enable API Access

API Examples

Terraform Integration

Backup and Restore

Manual Backup

Restore from Backup

Version Control Backups

Performance Optimization

Resource Configuration

Database Maintenance

Data Retention

Integration with Other Tools

Grafana Dashboard

Home Assistant Integration

Troubleshooting

Monitor False Positives

Notification Not Received

High Resource Usage

Database Corruption

Best Practices

Monitor Configuration

Notification Strategy

Security

Performance

Advanced Use Cases

Multi-Region Monitoring

Maintenance Windows

SLA Reporting

Next Steps

Additional Resources