How to Monitor Your Hong Kong VPS: Uptime, Performance, and Alert Setup Guide (2026)

A production Hong Kong VPS serving live users requires monitoring — you need to know about downtime, performance degradation, and resource exhaustion before your users do. Without monitoring, you discover problems when customers complain rather than when systems first show signs of stress.

This guide covers a complete monitoring stack for a Hong Kong VPS: external uptime monitoring, server-level performance metrics, disk and memory threshold alerts, and notification configuration — using free and open-source tools that run efficiently on entry-level hardware.

Monitoring Stack Overview

The monitoring setup in this guide uses three complementary tools:

• Uptime Kuma — External uptime monitoring with HTTP, TCP, ping, and DNS checks; alerting via Telegram, Slack, email, and more
• Netdata — Real-time server performance metrics (CPU, RAM, disk I/O, network, processes) with a built-in web dashboard
• Custom alerting scripts — Threshold-based alerts for disk space and memory that Netdata’s free tier does not cover

Step 1: Install Uptime Kuma

Uptime Kuma is a self-hosted uptime monitoring tool that checks your services from your own server and alerts you when they go down. Run it on your Hong Kong VPS or a separate monitoring VPS:

docker run -d \
  --name uptime-kuma \
  --restart=always \
  -p 3001:3001 \
  -v uptime_kuma_data:/app/data \
  louislam/uptime-kuma:1

Access the web interface at http://YOUR_VPS_IP:3001 and complete the initial admin account setup.

Add monitors for your services

In the Uptime Kuma interface, add monitors for:

• HTTP(s) monitor — checks your website URL returns a 200 OK response
• TCP port monitor — checks that MySQL (3306), Redis (6379), or custom application ports are accepting connections
• Ping monitor — basic ICMP ping to verify server network reachability
• DNS monitor — verifies your domain resolves to the expected IP address
• Keyword monitor — HTTP check that also verifies a specific string appears in the response body

Set check intervals to 60 seconds for production services. Configure notification channels:

• Settings → Notifications → Add Notification
• Choose your preferred channel: Telegram (recommended for instant mobile alerts), Slack, email, PagerDuty, or webhook

Step 2: Install Netdata for Real-Time Performance Monitoring

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh
bash /tmp/netdata-kickstart.sh --no-updates --stable-channel

Netdata installs as a systemd service and begins collecting metrics immediately:

systemctl status netdata

By default, Netdata’s dashboard is accessible at http://YOUR_VPS_IP:19999. Restrict access immediately — do not leave port 19999 open to the public internet:

sudo ufw deny 19999
sudo ufw allow from YOUR_HOME_IP to any port 19999

Or configure Nginx to proxy Netdata behind authentication:

location /netdata/ {
    auth_basic "Netdata Monitoring";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:19999/;
    proxy_set_header Host $host;
}

Key Netdata dashboards to monitor

• System CPU: Overall CPU utilisation and per-core breakdown
• Memory: RAM usage, swap usage (swap activity indicates memory pressure)
• Disk I/O: Read/write throughput and IOPS — spikes indicate application bottlenecks
• Network: Inbound/outbound bandwidth utilisation
• MySQL: Queries per second, slow queries, connection pool status
• Nginx: Active connections, requests per second, response codes
• Redis: Operations per second, memory usage, cache hit ratio

Step 3: Set Up Disk Space Alerts

Disk space exhaustion is one of the most common causes of production outages — databases stop writing, log rotation fails, and applications crash when disk fills to 100%. Alert at 80% and 90% thresholds:

nano /home/deploy/disk_alert.sh

#!/bin/bash
THRESHOLD_WARN=80
THRESHOLD_CRIT=90
TELEGRAM_TOKEN="your_bot_token"
TELEGRAM_CHAT_ID="your_chat_id"
HOSTNAME=$(hostname)

send_alert() {
    curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
        -d chat_id="${TELEGRAM_CHAT_ID}" \
        -d text="$1" > /dev/null
}

df -h | grep -vE '^Filesystem|tmpfs|cdrom' | while read line; do
    usage=$(echo $line | awk '{print $5}' | sed 's/%//')
    partition=$(echo $line | awk '{print $6}')
    
    if [ $usage -ge $THRESHOLD_CRIT ]; then
        send_alert "🔴 CRITICAL: Disk ${partition} on ${HOSTNAME} is ${usage}% full"
    elif [ $usage -ge $THRESHOLD_WARN ]; then
        send_alert "⚠️ WARNING: Disk ${partition} on ${HOSTNAME} is ${usage}% full"
    fi
done

chmod +x /home/deploy/disk_alert.sh

Schedule to run every 30 minutes:

crontab -e
# Add:
*/30 * * * * /home/deploy/disk_alert.sh

Step 4: Memory and Load Average Alerts

nano /home/deploy/resource_alert.sh

#!/bin/bash
TELEGRAM_TOKEN="your_bot_token"
TELEGRAM_CHAT_ID="your_chat_id"
HOSTNAME=$(hostname)
CPU_CORES=$(nproc)

send_alert() {
    curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
        -d chat_id="${TELEGRAM_CHAT_ID}" \
        -d text="$1" > /dev/null
}

# Check memory usage
TOTAL_MEM=$(free -m | awk '/^Mem:/{print $2}')
USED_MEM=$(free -m | awk '/^Mem:/{print $3}')
MEM_PCT=$((USED_MEM * 100 / TOTAL_MEM))

if [ $MEM_PCT -ge 90 ]; then
    send_alert "🔴 CRITICAL: Memory on ${HOSTNAME} is ${MEM_PCT}% used (${USED_MEM}MB / ${TOTAL_MEM}MB)"
elif [ $MEM_PCT -ge 80 ]; then
    send_alert "⚠️ WARNING: Memory on ${HOSTNAME} is ${MEM_PCT}% used"
fi

# Check load average (alert if > 2x CPU cores)
LOAD=$(uptime | awk -F'load average:' '{print $2}' | awk '{print $1}' | sed 's/,//')
LOAD_INT=$(echo "$LOAD * 10" | bc | cut -d. -f1)
THRESHOLD=$((CPU_CORES * 20))

if [ $LOAD_INT -ge $THRESHOLD ]; then
    send_alert "🔴 HIGH LOAD: ${HOSTNAME} load average is ${LOAD} (${CPU_CORES} CPU cores)"
fi

chmod +x /home/deploy/resource_alert.sh
crontab -e
# Add:
*/5 * * * * /home/deploy/resource_alert.sh

Step 5: Set Up Telegram Bot for Alerts

Telegram bots provide instant, free mobile push notifications for server alerts — more reliable than email for production incident response:

1. Message @BotFather on Telegram and send /newbot
2. Follow the prompts to create your bot and obtain the bot token
3. Start a conversation with your new bot and send any message
4. Retrieve your chat ID: https://api.telegram.org/bot{TOKEN}/getUpdates
5. Update the TELEGRAM_TOKEN and TELEGRAM_CHAT_ID variables in the alert scripts above

Test your alert setup:

curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
    -d chat_id="${CHAT_ID}" \
    -d text="Test alert from $(hostname) - monitoring is working"

Step 6: Log Monitoring for Security Events

# Monitor failed SSH login attempts in real time
journalctl -fu sshd | grep -E "Failed|Invalid"

# Daily summary of authentication events
grep "$(date --date='yesterday' '+%b %e')" /var/log/auth.log | \
  grep -E "Failed password|Invalid user" | \
  awk '{print $11}' | sort | uniq -c | sort -rn | head -20

Conclusion

A complete monitoring stack for your Hong Kong VPS — Uptime Kuma for external availability, Netdata for performance metrics, and custom scripts for resource threshold alerts — gives you visibility into your server’s health without requiring expensive commercial monitoring services. The entire stack runs on a 1 GB RAM VPS with minimal resource overhead.

Need a reliable foundation for your monitoring infrastructure? Server.HK’s Hong Kong VPS plans include NVMe SSD storage and CN2 GIA routing as standard — the stable foundation your monitoring tools and production applications require.

Frequently Asked Questions

Should I run monitoring on the same VPS I am monitoring?

For uptime monitoring specifically, running Uptime Kuma on the same VPS it is monitoring creates a blind spot — if the VPS goes down, Uptime Kuma goes down too and cannot alert you. For external availability monitoring, use a separate monitoring VPS, or use a free external service (Better Uptime free tier, UptimeRobot free tier) to check your primary VPS’s availability. Netdata and resource alert scripts can safely run on the same server they monitor.

How much RAM does Netdata use on a Hong Kong VPS?

Netdata typically uses 50–150 MB of RAM with default configuration, depending on the number of metrics collected and retention period. On a 1 GB RAM VPS, this is meaningful overhead — reduce metrics retention or disable unused plugins if RAM is constrained. On 2 GB+ VPS instances, Netdata’s resource footprint is negligible.

Can I monitor multiple Hong Kong VPS instances from a single Uptime Kuma installation?

Yes. Uptime Kuma supports unlimited monitors from a single installation — add HTTP, TCP, ping, and keyword monitors for as many servers and services as needed. A single Uptime Kuma instance can effectively monitor an entire fleet of VPS servers from one dashboard with unified alerting.