[{"data":1,"prerenderedAt":188},["ShallowReactive",2],{"seo-verification":3,"blog-proactive-vps-monitoring-beszel-uptime-kuma-v2-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-proactive-vps-monitoring-beszel-uptime-kuma-v2-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":130,"ctaBody":131,"ctaButton":132,"ctaUrl":133,"relatedPosts":134},440,"proactive-vps-monitoring-beszel-uptime-kuma-v2",{"fr":12,"en":10,"ar":13,"es":14},"monitoring-alerte-proactif-self-hosted-vps","مراقبة-استباقية-vps-beszel-uptime-kuma","monitorizacion-proactiva-vps-beszel-uptime-kuma-v2","Proactive VPS monitoring: Beszel and Uptime Kuma v2","Deploy Beszel and Uptime Kuma v2 on a VPS to monitor your entire server fleet and receive Telegram or SMTP alerts before your clients notice the outage.",11,0,false,"2026-10-14T00:00:00+00:00","2026-10-14T23:33:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmonitoring-alerte-proactif-self-hosted-vps-poster.svg","A PostgreSQL service stops without triggering any disk alert. The client calls. You learn about the outage at the same time they do. This scenario, documented and shared in the community in October 2026, illustrates the problem with single-layer monitoring stacks: each tool sees only what it watches, and nothing else. Beszel combined with Uptime Kuma v2 covers both angles — system metrics on every host, and end-to-end availability checks — at a resource cost lower than an idle WordPress instance.",[35,39,51,54,79,82,120,124,127],{"type":36,"title":37,"body":38},"h2","Why proactive monitoring matters, and why classic tools fall short","Reactive alerting — the kind that arrives after the client has already called — does not protect the relationship. It repairs it. The difference between the two is not luck: it is coverage.\n\nAn availability monitoring tool like Uptime Kuma checks that a service responds on a port or URL. It does not know whether PostgreSQL is running outside of that port, whether container memory is about to saturate, or whether the log disk is filling at 200 MB per hour. Conversely, a system metrics tool like Beszel continuously monitors each host's resource consumption, but does not test application services end-to-end.\n\nThe case documented on \u003Ca href=\"https:\u002F\u002Flemmy.world\u002Fpost\u002F52895878\">Lemmy\u003C\u002Fa> on 11 October 2026 (112 votes) illustrates exactly this: PostgreSQL had stopped on a VPS without triggering any disk alert. No space threshold had been crossed. Only an application-level check would have detected the stop — which the operator did not have in place.\n\nThe Beszel + Uptime Kuma v2 stack addresses both angles. Beszel monitors each host's metrics (CPU, RAM, disk, network, containers) from a central hub. Uptime Kuma v2 checks the availability of exposed services with configurable alert channels. Both are open source, self-hosted, and install on a VPS dedicated to supervising your fleet.",{"type":40,"title":41,"items":42},"ul","What this stack delivers to an agency",[43,44,45,46,47,48,49,50],"Unified view of all your client servers in a single Beszel interface, without multiplying SSH access.","Metric alerts (CPU, RAM, disk, network) with configurable thresholds per host.","HTTP(s), TCP, DNS, and SSL certificate availability checks via Uptime Kuma v2 — every 60 seconds by default.","Telegram or SMTP notifications live within the first hour, no third-party subscription required.","Detection of disk saturation or memory leaks before they block an application service.","Public Uptime Kuma status pages shareable with end clients.","Total stack consumption under 150 MB of RAM on the monitoring VPS.","Reproducible deployment via Docker Compose, versionable and redeployable in minutes.",{"type":36,"title":52,"body":53},"Resource requirements","To host the Beszel hub and Uptime Kuma v2 on a dedicated monitoring VPS:\n\n**Minimum resources.** A 1 vCPU VPS with 1 GB of RAM is sufficient to monitor around ten hosts with Beszel and around fifty monitors with Uptime Kuma. In practice, Beszel hub uses around 50 MB of RAM and Uptime Kuma v2 around 100 MB — under 200 MB total at rest, according to community measurements. For a fleet of 20 to 50 VPS, plan for 2 GB of RAM. Beszel stores data in SQLite; allow 5 to 10 GB of disk to retain several months of history.\n\n**Software requirements.** Docker and Docker Compose installed on the monitoring VPS. A domain or subdomain pointing to this VPS (`monitoring.your-domain.com`) for the reverse proxy and SSL. Ports 80 and 443 open for the reverse proxy, and port `8090` or any port of your choice for the Beszel hub.\n\n**On supervised VPS.** Each host to be monitored only receives the Beszel agent — a lightweight binary or Docker container using around 10 MB of RAM. No public firewall changes are required: the agent initiates the connection to the hub, not the other way around.",{"type":55,"title":56,"steps":57},"steps","Full deployment: Beszel hub, agents, Uptime Kuma v2 and alerts",[58,61,64,67,70,73,76],{"title":59,"body":60},"Create the Docker Compose structure on the monitoring VPS","Connect to the VPS dedicated to monitoring. Create a working directory and the Compose file:\n\n```bash\nmkdir -p \u002Fopt\u002Fmonitoring && cd \u002Fopt\u002Fmonitoring\n```\n\nCreate `docker-compose.yml` with both services:\n\n```yaml\nservices:\n  beszel:\n    image: henrygd\u002Fbeszel:latest\n    restart: unless-stopped\n    volumes:\n      - .\u002Fbeszel_data:\u002Fbeszel_data\n    ports:\n      - \"8090:8090\"\n    environment:\n      - DATA_DIR=\u002Fbeszel_data\n\n  uptime-kuma:\n    image: louislam\u002Fuptime-kuma:2\n    restart: unless-stopped\n    volumes:\n      - .\u002Fuptime-kuma-data:\u002Fapp\u002Fdata\n    ports:\n      - \"3001:3001\"\n    healthcheck:\n      test: [\"CMD\", \"node\", \"extra\u002Fhealthcheck\"]\n      interval: 30s\n      timeout: 10s\n      retries: 3\n```\n\nNote the `healthcheck` block on Uptime Kuma: it is essential to avoid the crash-loop trap (see the Pitfalls section).",{"title":62,"body":63},"Start the stack and create administrator accounts","Start both containers:\n\n```bash\ndocker compose up -d\n```\n\nCheck that both containers are in `healthy` or `running` state:\n\n```bash\ndocker compose ps\n```\n\nAccess Beszel at `http:\u002F\u002F\u003Cvps-ip>:8090` and create the administrator account on first access. Do the same for Uptime Kuma at `http:\u002F\u002F\u003Cvps-ip>:3001`. Both interfaces should then be placed behind a reverse proxy with SSL to avoid exposing them over plain HTTP.",{"title":65,"body":66},"Deploy the Beszel agent on each VPS to monitor","On each client VPS to be monitored, copy the public key generated in the Beszel interface (Settings → SSH Key), then run:\n\n```bash\ncurl -sL https:\u002F\u002Fraw.githubusercontent.com\u002Fhenrygd\u002Fbeszel\u002Fmain\u002Fsupplemental\u002Fscripts\u002Finstall-agent.sh | bash -s -- -p 45876 -k \"\u003Cyour-public-key>\"\n```\n\nAlternatively, use Docker on the supervised host:\n\n```yaml\nservices:\n  beszel-agent:\n    image: henrygd\u002Fbeszel-agent:latest\n    restart: unless-stopped\n    network_mode: host\n    volumes:\n      - \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock:ro\n    environment:\n      - KEY=\u003Cyour-public-key>\n      - PORT=45876\n```\n\nIn Beszel, add each host from the interface (Systems → Add System) with its IP and agent port. The connection is established from the hub to the agent: the supervised host does not need to expose this port publicly.",{"title":68,"body":69},"Configure metric alerts in Beszel","In Beszel, open a system's detail page and go to the Alerts tab. Configure thresholds on critical metrics:\n\n- **Disk**: alert at 80% and critical at 90% — covers the PostgreSQL scenario from the opening case.\n- **RAM**: alert if usage exceeds 85% sustained for 5 minutes.\n- **CPU**: alert if load exceeds 90% for more than 3 minutes.\n\nBeszel supports Telegram, Discord, Slack, Gotify, Ntfy and generic webhooks. For Telegram, you need a bot token (obtained via `@BotFather`) and your chat or group ID.",{"title":71,"body":72},"Configure Uptime Kuma v2 monitors and SMTP or Telegram alerts","In Uptime Kuma, start by configuring a notification channel (Settings → Notifications). Two common options:\n\n**Telegram.** Enter the bot token and chat ID. The same bot as for Beszel works — use a single bot for both tools and distinguish them by different channels.\n\n**SMTP.** Enter the SMTP server, port (587 with STARTTLS), credentials, and destination address. Use a dedicated account for alert sending.\n\nThen create monitors for each critical service: HTTP(s) URL for websites, TCP for databases and application ports. For the PostgreSQL case, add a TCP monitor on port `5432` for each VPS hosting an instance — if PostgreSQL stops, the port stops responding and the alert fires within seconds.",{"title":74,"body":75},"Put everything behind a reverse proxy with SSL","Add an nginx or Caddy service to the Compose to expose Beszel and Uptime Kuma over HTTPS:\n\n```yaml\n  caddy:\n    image: caddy:alpine\n    restart: unless-stopped\n    ports:\n      - \"80:80\"\n      - \"443:443\"\n    volumes:\n      - .\u002FCaddyfile:\u002Fetc\u002Fcaddy\u002FCaddyfile\n      - caddy_data:\u002Fdata\n```\n\nWith a minimal `Caddyfile`:\n\n```\nmonitoring.your-domain.com {\n    reverse_proxy beszel:8090\n}\n\nstatus.your-domain.com {\n    reverse_proxy uptime-kuma:3001\n}\n```\n\nCaddy automatically issues and renews Let's Encrypt certificates. Remove the `ports` sections from beszel and uptime-kuma in the Compose once they are proxied — they should no longer be directly accessible.",{"title":77,"body":78},"Verify the setup and configure data retention","Test everything by manually stopping a service on a test VPS (`docker compose stop \u003Cservice>`) and verifying that the Telegram or SMTP alert arrives within two minutes.\n\nFor Beszel, configure data retention in Settings → Retention: the default is 7 days for high-resolution data and 30 days for hourly aggregates. Adjust based on your disk capacity.\n\nFor Uptime Kuma, retention is configured in Settings → Advanced → Auto Cleanup. Keep at least 90 days to have monthly uptime trends to present to clients.",{"type":36,"title":80,"body":81},"Pitfalls to know before going to production","**The Docker crash-loop reported as UP — Uptime Kuma issue #7956.** Without a `healthcheck` in the Compose, Docker may report an Uptime Kuma container as `running` while it is in a restart loop. The Uptime Kuma monitor watching itself (TCP on port 3001) would show a false positive: the port responds during the brief window between two restarts. The workaround is exactly the `healthcheck` block shown in step 1 — it uses the script embedded in the image to test the application's internal state, not just process presence. Docker then marks the container as `unhealthy` if the check fails three times in a row, and the Uptime Kuma monitor sees it.\n\n**Beszel agent with `network_mode: host`.** If supervised hosts run containers, the Beszel agent needs access to the Docker socket (`\u002Fvar\u002Frun\u002Fdocker.sock`) to report per-container metrics. In bridge network mode the socket is accessible but the IP reported by the agent may be the internal Docker network address. Prefer `network_mode: host` on the agent to ensure the Beszel hub sees the server's public IP.\n\n**Beszel alerts do not replace application-level checks.** Beszel monitors system resources and Docker container availability. It does not test that an application correctly responds to an HTTP request or that PostgreSQL accepts connections. These two levels are complementary: Beszel detects the saturation that precedes an outage, Uptime Kuma confirms the outage when it happens.",{"type":83,"title":84,"headers":85,"rows":90},"comparison","Alert coverage by stack configuration",[86,87,88,89],"Failure scenario","Beszel only","Uptime Kuma only","Beszel + Uptime Kuma v2",[91,96,101,106,110,115],[92,93,94,95],"Disk full at 95%","Alert at configured threshold","Not detected","Beszel alert before failure",[97,98,99,100],"PostgreSQL stopped (TCP port down)","Not detected (non-Docker service)","TCP alert in \u003C 2 min","Uptime Kuma TCP alert",[102,103,104,105],"Container in crash-loop","Alert if CPU\u002FRAM impacted","False positive without healthcheck","Detected if healthcheck in place",[107,108,94,109],"Progressive memory leak","Alert on RAM threshold","Anticipatory Beszel alert",[111,112,113,114],"SSL certificate expiring in 7 days","Not monitored","SSL expiry alert","Uptime Kuma SSL alert",[116,117,118,119],"VPS unreachable (network or host down)","Hub loses agent","TCP\u002FHTTP alert","Double signal, convergent",{"type":121,"title":122,"body":123},"tip","Hardening: isolate the monitoring VPS","The monitoring VPS is a critical asset: if it goes down, you lose visibility across everything else. Three rules to harden it.\n\nFirst, do not host client applications on this VPS. Its load must remain predictable and its sole role is monitoring.\n\nSecond, close all unnecessary ports with your VPS firewall. Only 80, 443, and the SSH port (moved to a non-standard port) should be accessible from the internet. The Beszel agent port (45876 by default) should only be open from the IPs of your other VPS, not from the entire internet.\n\nThird, add an external Uptime Kuma monitor — for example from a free HTTP check service — that verifies your own Uptime Kuma instance responds. Without this external layer, a failure of the monitoring VPS itself goes unnoticed.",{"type":36,"title":125,"body":126},"Troubleshooting common issues","**Beszel agent appears offline immediately after adding.** Check that the agent port (45876 by default) is reachable from the hub. On the supervised host, test with `nc -zv \u003Chub-ip> 8090` — if the connection fails, the problem is with the hub's firewall. The agent itself does not require any inbound port to be open.\n\n**Uptime Kuma is not receiving Telegram alerts.** The most common cause is a clock drift on the container. Check with `docker exec uptime-kuma date` that the time matches real UTC time. If not, add `\u002Fetc\u002Flocaltime:\u002Fetc\u002Flocaltime:ro` to the Uptime Kuma service volumes.\n\n**Beszel hub does not start or loses data after a restart.** Check that the `.\u002Fbeszel_data` volume belongs to the UID used by the Beszel container. A permissions error on the data directory prevents SQLite from writing: `chown -R 1000:1000 .\u002Fbeszel_data` fixes the issue in most cases.\n\n**Uptime Kuma `unhealthy` at startup.** The v2 image can take 30 to 60 seconds to fully start before the healthcheck passes. This is normal. If the container stays `unhealthy` after two minutes, check the logs: `docker compose logs uptime-kuma`.",{"type":36,"title":128,"body":129},"Going further","This stack covers the two essential levels: system metrics and availability checks. For a third level — traceability and fine-grained load trend analysis — the Grafana + Prometheus stack is a natural next step. It is more resource-intensive (plan for 2 GB of dedicated RAM), but opens up PromQL and custom dashboards. The article \u003Ca href=\"\u002Fblog\u002Fmonitoring-vps-grafana-prometheus\">VPS monitoring with Grafana and Prometheus\u003C\u002Fa> covers that deployment step by step.\n\nFor backups of the monitoring VPS itself — to avoid rebuilding all the configuration after a loss — the \u003Ca href=\"\u002Fblog\u002Fbackup-vps-restic-s3-3-2-1\">3-2-1 strategy with Restic and S3 storage\u003C\u002Fa> applies directly to this stack's Docker volumes.\n\nIf you manage several client servers from a single platform, the \u003Ca href=\"\u002Fsolutions\u002Fagences\">\u002Fsolutions\u002Fagences\u003C\u002Fa> page details how ServOrbit centralises fleet monitoring on a VPS Start.","Monitor your fleet from a single VPS","You manage multiple client servers. Centralise fleet monitoring on a ServOrbit VPS with root access, dedicated IPv4 and Docker — the Beszel + Uptime Kuma v2 stack fits on the entry-level plan.","Monitor my fleet","\u002Fsolutions\u002Fagences",[135,154,171],{"id":136,"slug":137,"slugs":138,"title":142,"excerpt":143,"readTime":144,"views":18,"isPinned":19,"publishedAt":145,"updatedAt":146,"category":147,"categories":148,"featuredImage":30,"bgImage":31,"posterImage":150,"relatedSolution":151},105,"monitoring-your-vps-with-uptime-kuma",{"fr":139,"en":137,"ar":140,"es":141},"superviser-vps-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","supervisar-vps-con-uptime-kuma","Monitoring your VPS with Uptime Kuma","Deploy Uptime Kuma on your VPS to monitor your sites and services self-hosted, with alerts and a public status page.",4,"2026-03-07T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[149],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":152,"appSlug":153},"monitoring-observability","uptime-kuma",{"id":155,"slug":156,"slugs":157,"title":161,"excerpt":162,"readTime":23,"views":163,"isPinned":19,"publishedAt":164,"updatedAt":146,"category":165,"categories":166,"featuredImage":30,"bgImage":31,"posterImage":168,"relatedSolution":169},133,"self-host-beszel-multi-server-monitoring-hub-on-your-vps",{"fr":158,"en":156,"ar":159,"es":160},"self-host-beszel-vps","استضف-beszel-على-vps-مركز-مراقبة-متعدد-الخوادم","alojar-beszel-hub-monitorizacion-vps","Beszel on VPS: multi-server monitoring, alerts and security","Deploy Beszel on a VPS, monitor your entire fleet from one hub, set up Telegram\u002Femail alerts, enable 2FA and fix silent agents, TLS errors and blocked ports.",1,"2026-02-14T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[167],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-beszel-vps-poster.svg",{"categorySlug":152,"appSlug":170},"beszel",{"id":172,"slug":173,"slugs":174,"title":178,"excerpt":179,"readTime":17,"views":18,"isPinned":19,"publishedAt":180,"updatedAt":181,"category":182,"categories":183,"featuredImage":30,"bgImage":31,"posterImage":185,"relatedSolution":186},106,"vps-monitoring-with-grafana-and-prometheus",{"fr":175,"en":173,"ar":176,"es":177},"monitoring-vps-grafana-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","monitorizacion-vps-grafana-prometheus","VPS Monitoring with Grafana and Prometheus","Deploy Prometheus 3.x, Grafana 13.x, Node Exporter and Alertmanager on your VPS with Docker Compose. Dashboards, alerts and hardening.","2026-03-06T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[184],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":152,"appSlug":187},"grafana",1792031964167]