Self-Hosted Server Monitoring with Uptime Kuma, Prometheus and Grafana from a Second Location

Self-hosted server monitoring means running your own uptime checks, metrics and alerts on a server you control, and its first rule is that the watcher must not live on the server it watches. Put Uptime Kuma on a small VPS in another city to check your sites from outside, and add Prometheus with Grafana to see what happens inside them. Picture a shop on a VPS in Amsterdam with Uptime Kuma on that same VPS: late one Saturday the disk fills, checkout breaks, and the alarm stays silent, because it sits inside the failure.

The night as a timeline, invented but built from failures people report all the time:

• 22:10. A log file nobody rotates eats the last free space on the disk. MySQL stops writing.
• 22:11. The homepage still loads from cache. Checkout shows the theme's error page, with HTTP status 200.
• 22:12. Uptime Kuma fetches the homepage, gets its 200 and stays green.
• 23:40. A customer gives up and messages your Instagram.
• Sunday, 09:15. You read it over breakfast.

The check asked the wrong question, and the checker shared the full disk. Plenty of companies find out the same way: in New Relic's 2026 Observability Forecast, published on 22 September 2026 from a survey of 2,575 engineering and IT people, 42% of organisations said they still learn about disruptions through manual checks and customer complaints.

At a glance: host the monitor on its own small VPS in another location. Use Uptime Kuma for outside checks with Telegram alerts, raising its retries because by default it alerts on the first failed check. Add Prometheus, Alertmanager and Grafana to learn why a server is slow, and let something outside watch the monitor.

Why should monitoring run on a different server?

Monitoring has to survive the failure it reports. If the watcher shares a disk or a network with the servers it checks, the outage that takes them down silences it too, and no alert ever leaves. A small VPS in another location keeps watching when the first one goes dark.

Big operators trip over this too. During the S3 outage of 28 February 2017, AWS could not update individual services on its own Service Health Dashboard until 11:37 AM PST, because the dashboard's admin console depended on S3 (AWS's summary of the event). The Prometheus documentation calls the cure meta-monitoring: check that the monitoring itself works.

With RS Computers the watcher and the watched can sit in different countries: our KVM servers run in Amsterdam (Netherlands), Prishtina (Kosovo) and Dublin (Ireland), so host the sites in Amsterdam and the monitor in Dublin, or the reverse. Pick whichever second city the VPS and VDS plans page shows as available.

Published downtime costs come from large organisations, so treat them as a direction, not a forecast for a small shop. In the Uptime Institute's Annual Outage Analysis 2026, 57% of respondents said their most recent major outage cost six figures or more, and for the second year running one in five said seven figures.

Self-hosted server monitoring: what to watch first

Whatever tools you pick, start with what a customer would notice, then work inwards:

1. The page that earns money loads with the right text. A status-code check passes an error page served with 200; a keyword check catches it. Watch checkout or login, not just the homepage.
2. TLS certificates. Let's Encrypt stopped sending expiry emails on 4 June 2025, and the CA/Browser Forum voted in 2025 to cut the maximum lifetime of public certificates from 398 days to 47, in steps that began in March 2026. Let's Encrypt already issues 45-day certificates to anyone who picks its tlsserver profile, since 13 May 2026, and has announced that its default drops from 90 days to 64 in February 2027. Each extra renewal is one more chance for a certificate to lapse without anyone noticing.
3. Domain expiry: rare, but it takes email down too.
4. Reachability: ping and TCP checks on SSH or database ports. In Prometheus, up drops to 0 when a scrape fails.
5. Backup heartbeats. A failed nightly backup looks like a good one until you need it.
6. Disk below about 10% free.
7. Memory under 10% available for minutes. The out-of-memory killer is next, and it often picks the database.
8. CPU and load: dashboard material, rarely worth waking anyone for.

The top half are symptoms, the bottom half causes. Google's SRE book builds alerting on that split, with four golden signals (latency, traffic, errors, saturation) and the rule that every page must need a human (Monitoring Distributed Systems). The Prometheus alerting guidelines agree: alert on symptoms and avoid pages where there is nothing to do.

Uptime Kuma vs Prometheus and Grafana: do you need both?

They answer different questions. Uptime Kuma is a free, open-source monitor you host yourself: it probes services from outside (HTTP, TCP, ping, DNS and more), tracks certificates, publishes status pages and alerts through 90+ notification services. Prometheus is a time-series database that pulls metrics from small agents called exporters, such as node_exporter for Linux; Alertmanager sends its alerts and Grafana draws the dashboards. Kuma says checkout takes eight seconds. Prometheus shows the backup job saturating the disk that minute.

Beszel is a lightweight hub-and-agent server monitor; Netdata is a per-second metrics agent with its own dashboard. Beszel 0.20, released on 19 September 2026, added network monitors that its agents run (ping, TCP, HTTP and DNS), but the HTTP check only fails on an error or a status of 400 and up, so that Saturday's checkout page would have passed it too. If PromQL (Prometheus's query language) and YAML are new to you, rehearse first on a Linux and DevOps practice lab on a VPS.

Why self-host instead of a hosted uptime service?

Hosted checkers are handy, and one appears below to watch the monitor. As your only monitoring, though, free tiers cap monitors, check every few minutes and see only public endpoints. Self-hosted server monitoring drops those limits: Uptime Kuma has no monitor cap, checks every 60 seconds by default, keeps 365 days of history and can test a database port open only to your monitor (our guide to running PostgreSQL, MySQL and Redis on a VPS covers that allowlist). You do have to patch it and back it up yourself.

How big does the monitoring VPS need to be?

A monitor is light work: it sends small requests and stores numbers. Each of our plans gives it a KVM machine on NVMe with unmetered traffic, a 1 Gb/s port (10 Gb/s on VDS) and its own IPv4 and IPv6 address, and you pick the Linux distribution when you order. When the monitor outgrows its plan, upgrade it from the client area; it stays the same server after a short reboot.

These sizes are our estimate for the whole stack, since no vendor publishes one. Grafana's own docs give 512 MB of RAM as the minimum and 2 to 4 GB for a small team, a tier that assumes up to 25 people using it at once, not one admin. Prometheus stores about 1 to 2 bytes per sample and keeps 15 days by default, so ten servers with roughly 1,000 series each (an assumption; the query scrape_samples_scraped in Prometheus shows yours per server), scraped every 15 seconds, need about 0.9 to 1.7 GB.

For a real number: on a spare 8 vCPU test server in our network, with 16 GB of RAM, the finished stack from this guide, watching two servers (two keyword monitors in Kuma, two scrape targets in Prometheus), used about 380 MB of RAM (Kuma 144 MB, Grafana 142 MB, Prometheus 52 MB, Alertmanager 25 MB, Caddy 15 MB), or about 550 MB counting Docker and the system itself. Its Docker data took about 4 GB of disk: 1 GB of downloaded image layers plus 3 GB unpacked.

Setup 1: Uptime Kuma with Telegram alerts

Run this part on the monitoring VPS, a fresh Debian 13 server, as root (on Ubuntu 24.04 or 26.04, type sudo -i first). Point a DNS name at it with A and AAAA records; it appears below as KUMA_DOMAIN. Kuma cannot live under a sub-path, so give it a whole name.

Step 1: update and switch on the firewall

This updates the system and opens SSH and the web ports before the firewall goes on.

# as root
apt update && apt upgrade -y
apt install -y curl ca-certificates gnupg ufw
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable
ufw status verbose

The last line shows Status: active with ALLOW rules for 22, 80 and 443. Allow 22 before enabling, or you lock yourself out.

Step 2: install Docker from Docker's repository

Docker is Kuma's recommended install. Use Docker's own repository rather than Debian's docker.io 26.1.5: Docker documents that before 28.0.0, ports published on 127.0.0.1 could be reached from other hosts on the same network segment. This block adds the repository and installs Docker with Compose.

# as root
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
docker run hello-world

Look for Hello from Docker!; docker version should report Engine 29.8.2 or newer. On Ubuntu 24.04 or 26.04, write ubuntu instead of debian in both URLs and use ${UBUNTU_CODENAME:-$VERSION_CODENAME} on the Suites line. Our Docker, Compose and Portainer guide goes further into Compose and the firewall trap described in the next step.

Step 3: start Uptime Kuma

This writes Kuma's official Compose file, changed to publish the port on 127.0.0.1 only, and starts it.

# as root
mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma
cat > compose.yaml <<'EOF'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
EOF
docker compose up -d
sleep 20
docker compose ps
curl -I http://127.0.0.1:3001

The pause gives Kuma a moment to start; without it curl can fail with "Connection reset by peer". docker compose ps shows Up, usually already (healthy) (it can take up to three minutes), and curl prints HTTP/1.1 302 Found with Location: /setup-database. The 127.0.0.1 is deliberate: ports that Docker publishes skip ufw, so a plain 3001:3001 would expose the login page whatever your firewall says. Avoid the :latest tag from older guides; it is deprecated and still means version 1.

Step 4: put HTTPS in front with Caddy

Caddy fetches and renews the certificate and passes Kuma's WebSocket through untouched. Debian 13's own caddy package is version 2.6.2 from 2022, while the 2.11 releases of 2026 fixed a string of security holes, so this block adds Caddy's own repository, installs Caddy from it and points it at Kuma.

# as root
apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
chmod o+r /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install -y caddy
cat > /etc/caddy/Caddyfile <<'EOF'
KUMA_DOMAIN {
    reverse_proxy 127.0.0.1:3001
}
EOF
systemctl reload caddy
caddy version
systemctl status caddy --no-pager

caddy version prints v2.11.7 or newer, the status shows active (running), and https://KUMA_DOMAIN should open Kuma's setup page. If it does not, journalctl -u caddy -n 30 usually shows a certificate error, which means DNS does not point here yet. The same lines work on Ubuntu. Prefer nginx or Traefik? Our reverse proxy and SSL guide covers both; nginx needs the Upgrade and Connection headers, or Kuma loops on "Cannot connect to the socket server. Reconnecting...".

Step 5: claim the admin account straight away

Do this now. Kuma 2 first asks for a database: SQLite for a small setup, the embedded MariaDB for hundreds of monitors. Then comes "Create your admin account", and until it exists, anyone who reaches the page can create one. Afterwards, turn on two-factor authentication (Settings, Security) and set Trust Proxy to Yes (Settings, Reverse Proxy).

Step 6: connect Telegram

1. Send /newbot to @BotFather in Telegram and pick a name. It replies with a token.
2. Send your new bot any message, or add it to a group and post there.
3. In Kuma, open Settings, Notifications, Set Up Notification, choose Telegram, paste the token and click Auto Get to fill in the Chat ID. Note that number for later.
4. Tick Default enabled and Apply on all existing monitors, then press Test.

"Chat ID is not found; please send a message to this bot first" means you skipped the second step.

Step 7: add monitors worth having

For each site, add an HTTP(s) - Keyword monitor on the page that matters, then fix two defaults. New monitors start with 0 retries, so one lost packet pages you; set 2 or 3. The certificate expiry notification stays off until you tick it under Advanced, then warns at 21, 14 and 7 days. Domain Expiry Notification, added in 2.1, is already ticked on new monitors in the current 2.5 releases; leave it on. Add TCP Port monitors for SSH and database ports, using real IPv4 addresses: inside the container localhost is Kuma itself, and Docker gives containers no IPv6 by default.

For a backup job, add a Push monitor with a Heartbeat Interval of 90000 seconds (25 hours) and copy its Push URL. No nightly off-site backup yet? Our guide to off-site backups with restic sets one up. This crontab line calls the Push URL only when the backup succeeds.

# as root: run crontab -e on the server that does the backup and add the line below
30 3 * * * YOUR_BACKUP_COMMAND && curl -fsS -m 10 "https://KUMA_DOMAIN/api/push/PUSH_TOKEN?status=up&msg=OK" > /dev/null

Run the curl part by hand once: it prints {"ok":true} and the monitor turns green. Miss a night and it turns red.

Setup 2: Prometheus, node_exporter, Alertmanager and Grafana

node_exporter goes on each watched server. Prometheus 3.13.4 (from the current long-term-support line), Alertmanager 0.34.1 and Grafana 12.4.12 run on the monitor from their official Docker images, because Debian 13's own Prometheus package is the 2.53 line, whose upstream support ended in July 2025.

Why Grafana 12.4 when Grafana 13 came out in April 2026? Memory. On our test server, Grafana 13.2.3 used about 450 MB of RAM against about 140 MB for 12.4.12, because it starts a separate process for each of the dozen or so data source plugins it ships with. As the last 12.x line, 12.4 gets security fixes until 24 May 2027, a few days longer than 13.2 (Grafana's support table). If you have RAM to spare and want Grafana 13's new features, the steps below also ran unchanged with the tag 13.2.3.

Step 8: node_exporter on each watched server

If a watched server has no firewall yet, run step 1 on it first, with an allow line for each port it serves (80 and 443 for a website), so that ufw is installed and switched on before node_exporter opens port 9100. Replace MONITOR_IPV4 with the monitor's address. This installs Debian's node_exporter package, which runs as an unprivileged user, and opens port 9100 to the monitor only.

# as root, on each server you want to watch
apt install -y prometheus-node-exporter curl
ufw allow from MONITOR_IPV4 to any port 9100 proto tcp
curl -s localhost:9100/metrics | grep ^node_load1

Expect two lines, such as node_load1 0.05 and node_load15 0.02; if nothing appears, systemctl status prometheus-node-exporter says why. Debian 13 installs node_exporter 1.9.0; Ubuntu 24.04 ships an older version of the same package and Ubuntu 26.04 a newer one, 1.10.2, with the same commands. The scrape travels as plain HTTP, so for anything sensitive carry it over a WireGuard tunnel; our WireGuard guide for Debian 13 covers the keys, the server config and adding peers.

Step 9: write the Prometheus and Alertmanager configuration

Replace SERVER1_IP, SERVER2_IP, YOUR_CHAT_ID and YOUR_BOT_TOKEN first; the chat ID is a bare number without quotes, negative for groups. The block writes the scrape targets, two alert rules and a Telegram route, and makes the token readable only by the Alertmanager container's user.

# as root
mkdir -p /opt/monitoring/prometheus/rules /opt/monitoring/alertmanager
cd /opt/monitoring
cat > prometheus/prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]
rule_files:
  - "/etc/prometheus/rules/*.yml"
scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["SERVER1_IP:9100", "SERVER2_IP:9100"]
EOF
cat > prometheus/rules/basic.yml <<'EOF'
groups:
  - name: basic
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 5m
        labels:
          severity: page
      - alert: DiskAlmostFull
        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.10
        for: 10m
        labels:
          severity: ticket
EOF
cat > alertmanager/alertmanager.yml <<'EOF'
route:
  receiver: telegram
  group_by: ["alertname", "instance"]
receivers:
  - name: telegram
    telegram_configs:
      - bot_token_file: /etc/alertmanager/telegram_token
        chat_id: YOUR_CHAT_ID
EOF
printf '%s' 'YOUR_BOT_TOKEN' > alertmanager/telegram_token
chown 65534:65534 alertmanager/telegram_token
chmod 600 alertmanager/telegram_token
ls -l alertmanager

The listing shows telegram_token with -rw-------, owned by nobody nogroup, Debian's names for user and group 65534. The 15-second scrape interval is deliberate: without it Prometheus scrapes once a minute, its real default, whatever many tutorials claim.

Step 10: start Prometheus, Alertmanager and Grafana

This writes a Compose file with pinned versions and named volumes, validates both configurations with the tools inside the images, then starts everything on 127.0.0.1. The </dev/null on the two check lines keeps docker compose run from swallowing the pasted lines that follow it.

# as root
cd /opt/monitoring
cat > compose.yaml <<'EOF'
services:
  prometheus:
    image: prom/prometheus:v3.13.4
    restart: unless-stopped
    volumes:
      - ./prometheus:/etc/prometheus:ro
      - prometheus-data:/prometheus
    ports:
      - "127.0.0.1:9090:9090"
  alertmanager:
    image: prom/alertmanager:v0.34.1
    restart: unless-stopped
    command: ["--config.file=/etc/alertmanager/alertmanager.yml", "--storage.path=/alertmanager", "--cluster.listen-address="]
    volumes:
      - ./alertmanager:/etc/alertmanager:ro
      - alertmanager-data:/alertmanager
  grafana:
    image: grafana/grafana:12.4.12
    restart: unless-stopped
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "127.0.0.1:3000:3000"
volumes:
  prometheus-data:
  alertmanager-data:
  grafana-data:
EOF
docker compose run --rm --entrypoint promtool prometheus check config /etc/prometheus/prometheus.yml </dev/null
docker compose run --rm --entrypoint amtool alertmanager check-config /etc/alertmanager/alertmanager.yml </dev/null
docker compose up -d
sleep 20
docker compose ps
curl -s 127.0.0.1:9090/api/v1/targets | grep -o '"health":"[a-z]*"'

Both checks print SUCCESS, three containers show Up, and the last line prints one "health":"up" per server ("unknown" means no scrape yet; rerun it after 15 seconds). If a target stays down, run curl -s 127.0.0.1:9090/api/v1/targets | grep -o '"lastError":"[^,]*' to see why: "context deadline exceeded" means the watched server's firewall blocks the monitor, "connection refused" that node_exporter is not running.

Step 11: open Grafana and test the whole chain

Grafana stays off the public internet. From your own computer, run ssh -L 3000:127.0.0.1:3000 root@MONITOR_IPV4, open http://localhost:3000, log in as admin with password admin and set a real password when asked. Add a Prometheus data source at http://prometheus:9090 (inside Grafana's container, localhost is Grafana) and import the community dashboard "Node Exporter Full", ID 1860. Then test, because an alert path you never tried might as well not exist: run systemctl stop prometheus-node-exporter on one watched server. About six minutes later Telegram shows InstanceDown; start it again and an "Alerts Resolved" message follows within about five minutes.

How often should checks run, and how do you avoid alert fatigue?

Faster alerts are noisier alerts. With a 60-second interval and 2 retries 60 seconds apart, Kuma calls a site down after about three minutes; 3 retries at 30 seconds make the worst case two and a half. The Prometheus rule waits five minutes, plus up to 15 seconds of evaluation and Alertmanager's default 30-second group_wait: roughly six minutes, fine for a server alert because Kuma will have spoken already. Even that is far quicker than the 41 minutes that organisations in New Relic's 2026 survey took, on average, to detect a high-impact outage.

Since version 2.1, Kuma accepts intervals under 20 seconds once you accept a performance warning; shorter is rarely better. In Grafana Labs' 2026 Observability Survey, alert fatigue was again the most cited obstacle to faster incident response, named by 30% of respondents. What keeps the noise down:

• A for: clause on every Prometheus rule, so one failed scrape wakes nobody.
• Alertmanager's grouping, which by default waits 30 seconds before a group's first message and 4 hours before repeating an alert still firing.
• Telegram's limits, about one message per second per chat and 20 a minute in a group according to its bot FAQ. Forty monitors failing at once can hit them, so notify only on monitors that deserve a page.
• A second, muted chat for severity: ticket alerts.

How do you back up, update and watch the monitor itself?

Our free weekly backup restores the whole monitor from the client area, but by the time you need it, it can be almost a week old, so also keep a nightly copy of the monitor's own data. Copying Kuma's data folder, with Kuma stopped, is its only supported backup method since version 2 dropped the JSON export. This block archives it together with the monitoring configuration.

# as root
cd /opt/uptime-kuma
docker compose stop
tar czf /root/kuma-$(date +%F).tar.gz data
docker compose start
tar czf /root/monitoring-config-$(date +%F).tar.gz /opt/monitoring
ls -lh /root/*.tar.gz

Two archives with today's date should appear; tar's note about removing a leading "/" is normal. The second holds your bot token, so store copies somewhere private, and export any Grafana dashboards you customise as JSON.

To update Kuma, read the release notes, then run docker compose pull and docker compose up -d --force-recreate in its folder. For the other three, change the tags in compose.yaml and do the same in /opt/monitoring; node_exporter follows apt upgrade. Grafana 12.4 is the older line that still gets security fixes (13.2 is the newest), so read Grafana's upgrade guide before you move to 13, at the latest by May 2027. Prometheus ships a minor release about every six weeks; the newest, 3.15.0, came out on 24 September 2026. The 3.13 long-term-support line pinned here gets fixes until 31 July 2027, so until then you only bump the patch number.

Then watch the watcher. Aim a free hosted uptime check, or a tiny second Kuma in your third location, at https://KUMA_DOMAIN. Kuma's Globalping monitor type, added in 2.1, checks from community-hosted probes worldwide (250 tests an hour without an account), which shows whether a site is down for everyone or only for your monitor. Prometheus users add a dead man's switch: a Watchdog alert that always fires, sent to an outside receiver that complains when it stops. And repeat the step 11 test monthly.

Which parts of a monitoring server must stay off the internet?

A monitor holds a map of everything you run. In December 2024 Aqua Security found more than 296,000 Prometheus exporters and 40,000 Prometheus servers reachable online, many without authentication and some leaking credentials. The setup above avoids the usual holes; keep it that way:

• Ports published by Docker bypass ufw, so everything here except Caddy listens on 127.0.0.1. Prometheus and Alertmanager ship without a login, and anyone who reaches Alertmanager can silence real alerts.
• Update Grafana and Kuma promptly. Grafana shipped security releases on 2, 15 and 29 September 2026, and five Kuma releases fixed security issues during 2026, most recently 2.5.4 on 11 September; the 2 tag now pulls 2.5.5, from 16 September.
• Keep internal hostnames off public status pages, and personal data out of alerts: under EU case law even a dynamic IP address can be personal data.
• Netdata, if you try it, shows its dashboard on port 19999 to anyone; bind it to localhost.
• Lock down SSH on the monitor too, since it holds your bot token and a list of every server you run. Our Debian 13 image accepts root logins with a password, and a fresh test server we booted logged 261 failed SSH logins from 7 addresses within 78 minutes. Add an SSH key, then set PasswordAuthentication no; week 2 of our Linux lab guide has the exact steps. If you also switch off root login there, open the step 11 tunnel with your own user instead of root.

Frequently asked questions

Should monitoring run on the same server it monitors?

No. Monitoring that runs on the server it watches fails along with it, so a full disk or a network outage silences the alert together with the site. Use a separate VPS in another city, and leave only a small agent such as node_exporter on the watched servers.

What is the difference between Uptime Kuma and Prometheus? Do I need both?

Uptime Kuma checks from outside whether services answer; Prometheus collects metrics inside each server to explain why something is slow or running out. Start with Kuma, and add Prometheus and Grafana, or Beszel, once you run several servers.

Can Uptime Kuma monitor SSL certificate and domain expiry?

Yes. Every HTTPS monitor tracks its certificate, but the notification is off until you tick it under Advanced; it then warns at 21, 14 and 7 days. Version 2.1 added domain expiry notifications, which current releases switch on for every new monitor.

Is it safe to expose node_exporter port 9100 to the internet?

No. It has no login by default and describes your server in detail to anyone who asks. Allow 9100 only from the monitoring server's address, and when the traffic crosses the internet, add a WireGuard tunnel or node_exporter's TLS and basic-auth option.

Beszel or Netdata: which lightweight monitoring tool is better?

Beszel suits many small servers: one hub and light agents give history, threshold alerts and a server-down alert with little setup. Netdata suits per-second detail on a few busy machines, at 100 to 200 MB of RAM per agent on an idle server and 250 to 350 MB in typical production, with telemetry on until you set DISABLE_TELEMETRY=1. Neither checks a page for the right text the way an Uptime Kuma keyword monitor does, so pair either with Kuma.

Can RS Computers build the monitoring server for me?

Yes. Message us on Telegram or email info@rscomputers-ks.com with the sites and servers you want watched and where they run, and we will suggest a plan for the monitor and quote the setup.

Four things to do before Saturday

1. Order a small VPS in a different city from your servers on the VPS plans page. VPS Nano is enough to start.
2. Put Uptime Kuma behind Caddy and press Test on the Telegram notification until the message arrives (steps 1 to 6).
3. Add keyword monitors on the pages that earn money, with retries at 2 and certificate expiry on, plus a push monitor on the nightly backup.
4. Point one outside check at the monitor itself.

Prometheus and Grafana can wait for a quiet weekend; start on VPS Micro if you know you will want them, or upgrade from the client area later. Either way, keep that Saturday night hypothetical.

← All articles