CF-Server-Monitor: Free Multi-Server Monitoring on Cloudflare Workers

What CF-Server-Monitor Monitors

CF-Server-Monitor collects a broad set of server metrics through its Go agent. The feature table in the README lists CPU, GPU, memory, swap, disk, disk IO, network, connection count, process count, load average, and uptime as real-time metrics. Seven-day history charts are stored in D1 and include real-time network speed and monthly traffic statistics with correction support.

Network quality monitoring adds latency and packet loss tracking to nodes on China Telecom, China Unicom, China Mobile, and BGP networks. When the three-network detail mode is active, the frontend samples up to 20 real data points from the past two hours of D1 data and caches the result for five minutes.

Alert channels include offline notification when a server stops reporting, recovery notification when it comes back, expiry reminders for servers with a billing end date configured, and resource load alerts for CPU, memory, and disk thresholds. Version 2.8.6 added SMTP and custom Webhook alert channels alongside the existing notification options. An iOS Scriptable widget provides a quick-view summary on mobile.

The Cloudflare Workers Architecture

The architecture is unusual for a monitoring system. There is no dedicated monitoring server. The dashboard, API, database, and real-time push are all hosted on Cloudflare's infrastructure within the free tier limits.

The README describes the data flow as four steps. First, add a server in the admin panel and copy the generated install command. Second, run that command on the target server to install the Go agent, which begins reporting metrics to the Worker at the configured interval. Third, the Worker validates the API_SECRET on each report, writes the data to a D1 database, and broadcasts it through a Durable Object using WebSocket. Fourth, the Vue.js dashboard, admin panel, iOS widget, and any other frontend clients read from the same API.

The default reporting interval is 60 seconds. At that interval, the README states the free Cloudflare tier can support approximately 60 monitored servers. Doubling the interval to 120 seconds theoretically doubles the capacity. The agent also supports a WebSocket-based reporting mode introduced in version 2.8.4, which uses a configurable time window and falls back to POST requests outside that window to reduce Durable Object duration consumption on the free plan.

Deploying CF-Server-Monitor

Three deployment methods are described in the README. The recommended path connects a forked GitHub repository to Cloudflare Workers via the Cloudflare Dashboard, enabling automatic builds and redeployment on every push to main. The build command is:

npm run build:frontend

And the deploy command is:

npx wrangler deploy

After deployment, add an API_SECRET to the Worker's Variables and Secrets in the Cloudflare Dashboard.

The GitHub Actions path uses repository secrets to automate deployment. The required secrets are CF_API_TOKEN, CF_ACCOUNT_ID, D1_DATABASE_ID, and API_SECRET. An optional CORS_ALLOWED_ORIGINS secret restricts cross-origin API access. Pushing to main triggers the workflow automatically.

A one-click deploy button is also available for quick evaluation, but the README recommends migrating to the GitHub-connected or GitHub Actions path for long-term use because synchronising upstream updates is difficult with the one-click approach.

After deployment, the admin panel is at https://your-worker-domain/admin#/admin. The default username is admin and the default password is the API_SECRET value. The README recommends changing both immediately after first login.

The Go Agent and Platform Support

The monitoring agent ships as a Go binary from the separate cfsm-agent repository. The admin panel generates a complete install command for each server, including the server ID, Worker URL, API secret, reporting interval, network quality nodes, and network interface selection. The README recommends using this generated command rather than constructing it manually.

After installation, the agent runs as a service named cf-probe. On Linux systems that support systemd --user, the agent can run as a regular user without root privileges, with its files in ~/.cf-probe/. This is the non-root path described in the README.

Supported operating systems include mainstream Linux distributions, Alpine Linux, OpenWrt, macOS, Synology DSM, fnOS (Feiyun NAS OS), FreeBSD, and Windows. Docker image deployment is also supported. A Shell/PowerShell version of the agent is retained for platforms where the Go binary cannot run, but the Go version became the default in version 2.8.3.

The agent performs time correction using the HTTP Date header from the Worker's response to calibrate sample timestamps and boot time, reducing the effect of incorrect system clocks on history charts. The README states this does not modify the host's system time.

Free-Tier Boundaries and Known Constraints

The free-tier design is a deliberate constraint that shapes how CF-Server-Monitor works. The README describes several design decisions that reduce Cloudflare resource consumption: monthly table rotation for D1 writes, sampled queries with caching for history data, configurable WSS reporting windows that fall back to POST to limit Durable Object duration, and a 60-second default interval that was chosen to fit within free quota limits.

The approximately 60-server limit at the default interval is a theoretical figure based on Worker invocation counts; actual limits depend on D1 write quotas, Durable Object duration, and Worker CPU time, all of which vary with traffic patterns. High-frequency queries to the history charts or the three-network latency detail view consume more quota than idle monitoring.

The admin panel shows account Durable Object usage as of version 2.8.4. Teams approaching the free quota should monitor this figure and consider adjusting intervals or migrating to a paid Cloudflare plan. The project does not support sharding across multiple Cloudflare accounts to bypass quota limits.

CF-Server-Monitor vs. Uptime Kuma

Uptime Kuma is a self-hosted monitoring tool that runs as a Node.js application on a dedicated server or Docker container. It monitors services by making outbound checks (HTTP, TCP, ping, DNS) from the monitoring host, and presents results through a web interface. The fundamental difference from CF-Server-Monitor is that Uptime Kuma requires a dedicated host to run on.

CF-Server-Monitor inverts this: the monitored servers push metrics outbound to Cloudflare, and there is no monitoring host to maintain. This means CF-Server-Monitor has zero infrastructure cost for the dashboard itself, but it means monitoring depends on each server's outbound connectivity to Cloudflare's network.

Uptime Kuma's outbound check model is better for monitoring external URLs or services that CF-Server-Monitor's agent-based approach cannot reach. CF-Server-Monitor's agent provides deeper host-level metrics (CPU, disk IO, GPU) that Uptime Kuma's external checks cannot collect. The two tools address overlapping but distinct monitoring scenarios.

Editorial conclusion

CF-Server-Monitor is a good fit for individuals and small teams who want free, low-maintenance server monitoring without running a dedicated monitoring host. The Cloudflare Workers deployment means no VPS cost for the dashboard itself. The unidirectional agent design and non-root installation option reduce the attack surface compared to monitoring tools that accept commands from a central server. Teams with more than roughly 120 servers or who need sub-minute polling should check the free-tier limits against their requirements before deploying. Start with the admin panel's generated install command rather than constructing the agent command manually.

Frequently asked questions

Official sources

1. huilang-me/CF-Server-Monitor on GitHub
2. Issues
3. Project website
4. README