Self-Hosted Website Monitoring: Building Availability and Alerts with Uptime Kuma

“No monitoring” is the reason many small sites only discover faults after they occur—not because no one manages the server, but because no one knows there’s a problem. When users find out before you do, that delay itself is a loss.

The cost of building your own monitoring system is now very low. Uptime Kuma is an open-source, self-hosted monitoring tool that is easy to deploy and supports availability checks along with multiple alerting channels.

Why Self-Hosting is Recommended

Key principle: Monitoring must be independent of the monitored object. If monitoring is placed on the same server, it fails when the server crashes, rendering it useless.

Deployment (Docker Method)

# ① Install Docker (if not already installed)
curl -fsSL https://get.docker.com | bash
systemctl enable --now docker

# ② Start Uptime Kuma
docker run -d --restart=always 
  -p 3001:3001 
  -v uptime-kuma:/app/data 
  --name uptime-kuma 
  louislam/uptime-kuma:1

# ③ Verify running status
docker ps | grep uptime-kuma
ss -lntp | grep 3001

# ④ Access for initialization
# http://ServerIP:3001
# Create an admin account on first visit

It is recommended to deploy on a different machine from your business services (even if it’s a minimal specification instance). Deploying on the same machine means it will fail during a server outage.

# Restrict security group access to your own IP; do not expose port 3001 to the public internet
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="YourIP" port protocol="tcp" port="3001" accept'
firewall-cmd --reload

What to Monitor

“HTTP Check + Keyword” is much more useful than checking for a 200 status code alone. If you only check the status code, a page returning 200 but containing error content (e.g., a database connection failure page) will still be considered normal by the monitor.

Recommendation: Set "Response body must contain specific text" for key pages.
For example, the homepage should contain the site name, and APIs should contain "success".

Alert Channel Configuration

Alerts must actually reach people; otherwise, they are just records no one reads. Common channels include:

• Email (most basic)
• WeCom / DingTalk / Feishu bots (Recommended, high delivery rate)
• Webhook (can integrate with your own systems)

Configuration tips:
- Send a test notification first to confirm receipt
- Set the number of consecutive failures required for an alert (to avoid alerting on single fluctuations)
- Distinguish between "Down" and "Recovered" notifications

The “Consecutive Failures N times before alerting” setting is crucial. If set to 1, network jitter will cause you to receive useless alerts in the middle of the night, leading you to mute notifications eventually—making the entire monitoring setup pointless.

Command Line Supplement: Server Resource Monitoring

Uptime Kuma handles “external availability,” but you still need to check internal server status yourself:

#!/bin/bash
# /root/inspect.sh —— Perform resource inspection with cron
echo "--- Disk ---"; df -h | grep -vE 'tmpfs|overlay'
echo "--- Memory ---"; free -m
echo "--- Load ---"; uptime
echo "--- Failed Services ---"; systemctl --failed --no-pager

# Threshold alert (output prompt if disk usage exceeds 85%)
df -h | awk 'NR>1 {gsub("%","",$5); if ($5 > 85) print "Disk Alert: " $6 " " $5 "%"}'

0 9 * * * /root/inspect.sh >> /var/log/inspect.log 2>&1

Decision Tree

Set up Monitoring
├─ Deployment Location
│  └─ Different machine from business (otherwise both fail together)
├─ Monitor Items
│  ├─ Homepage + Key Pages (use keyword detection, don't just check 200)
│  ├─ Certificate Expiration Days
│  └─ Port Availability
├─ Alerts
│  ├─ Choose high-reachability channels (WeCom/DingTalk bots)
│  ├─ Set consecutive failure count to avoid false alarms from jitter
│  └─ Send a test notification to confirm receipt
└─ Internal Server
   └─ Script Inspection + Cron (Disk/Memory/Load/Service Status)

Scenario Simulation: Monitoring Shows All Green, But Users Report It’s Unavailable

Phenomenon: Your self-hosted availability monitoring shows all checkpoints are normal,
but simultaneously, users report that the site is inaccessible. The two pieces of information completely contradict each other.

1. First, determine which side is more likely wrong → User feedback comes from various networks and regions,
   while monitoring has only a single location. A single checkpoint’s conclusion cannot cover all users.
2. Check if the monitoring location is too singular → If monitoring is deployed on the same intranet or even the same machine,
   it fails along with the target object, unable to see anomalies.
3. Understand another possibility for “All Green” → Long detection intervals may leave intermittent faults in blind spots;
   crashes occurring between two checks won’t be recorded.
4. Move checkpoints externally → Use multiple checkpoints from different network locations,
   and ensure they do not share the same infrastructure as the monitored objects.
5. Shorten detection intervals and add consecutive judgment → Alert only after two consecutive failures,
   balancing sensitivity while avoiding false alarms from jitter.
6. Perform an active downtime verification → Intentionally create an unavailable state to confirm that alerts are actually received.

# Checkpoints must be independent of monitored objects (different machines/networks)
# Confirm if monitoring itself is alive—if monitoring fails, someone must know
systemctl is-active monitoring_service_name
pgrep -x monitoring_process_name >/dev/null && echo running || echo DOWN

# Test from an external perspective to compare with monitoring conclusions
curl -sS -o /dev/null -w '%{http_code}  %{time_total}sn' https://example.com/

# Alert channel self-check: Must verify actual receipt after configuration
curl -sS -X POST alert_channel_url -d 'text=Monitoring Self-Check (Ignore)' -o /dev/null -w '%{http_code}n'

Root Cause: Monitoring and the monitored object are in the same failure domain.
When they fail together, monitoring loses its observational capability, leading to a false “Everything is Normal” conclusion.

Two points worth remembering:

• The primary prerequisite for effective monitoring is “Independence from the monitored object.”
  Sharing the same machine, network, or power supply causes simultaneous failure at critical moments.
• “All Green” cannot be blindly trusted.
  The only way to judge if monitoring is truly working is to actively create a fault and see if the alert arrives.

Monitoring Items and Thresholds Reference

Two experiences from the table are worth emphasizing separately:
“Alert only after 2 consecutive failures” and “Alert if backup doesn’t run”.
The former prevents network jitter from turning alerts into noise; the latter is because backup failure is the only fault that doesn’t reveal itself automatically—if a service crashes, users tell you; if a backup fails, you only find out on recovery day.

# In addition to self-hosted monitoring, have basic inspections on the server side (can be added to cron)
# Disk
df -h | awk 'NR>1 && $5+0 > 80 {print "DISK WARN:", $6, $5}'

# Load (compare with core count)
awk '{print "load1:", $1, " cores:", '"$(nproc)"'}' /proc/loadavg

# Certificate remaining days
end=$(echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -enddate | cut -d= -f2)
echo "Remaining Days: $(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 ))"

# Check if key processes are running
pgrep -x nginx >/dev/null || echo "NGINX DOWN"

After deploying monitoring, one step cannot be skipped: actively create a fault to confirm that alerts are actually received.
Assuming it works just because it’s configured is the most common reason for monitoring failure;
the only reliable criterion is whether you have ever received an alert from it.

8 Common Pitfalls

1. Deploying monitoring on the same machine: Both fail together during an outage.
2. Only checking status code 200: Cannot detect incorrect page content; keywords must be added.
3. Alert channels not receiving messages: Must send test notifications to verify.
4. Alerting on a single failure: False alarms from jitter lead to notifications being muted.
5. Not monitoring certificate expiration: Expiry is a predictable fault.
6. Port 3001 open to the entire internet: Access sources should be restricted.
7. No recovery notifications: You won’t know when things are restored.
8. Not reviewing historical data after setup: Trend information is key to locating root causes.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud markets (service providers include our store and peers, provided solely for reference of real feedback, not fictional tickets from this site):

b****4 Rating: 5.0 2025-06-23 16:57 b****4 Rating: 5.0 2025-06-23 16:56 Jian****Wei Rating: 5.0 2021-01-20 15:03 Technology is awesome, speed is fast! Originally caused by a Trojan causing global Baidu hijacking!!!!1 f****u Rating: 5.0 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 2020-11-20 10:03 Consistently good service 1****1 Rating: 5.0 2020-11-17 09:13 Thanks for the consistently good service. 1****1 Rating: 5.0 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 2020-08-24 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 2020-07-24 09:49 Many thanks! 1

10***77 2022-09-19 5.0 Affordable price | Skilled technology | Patient and professional Received filing rectification notice, found this service just in time, handled quickly 10***49 2022-04-12 5.0 On-time delivery | Affordable price | Skilled technology Needed rectification, configured quickly, not bad