I Built a Server Agent Because Uptime Checks Tell You What Failed, Not Why

A status page has a blind spot. It can tell you that your API is returning 502s. It can tell you that a TCP port stopped accepting connections. It can tell you when the incident started. It usually cannot tell you why. Was the application host out of memory? Was disk I/O saturated? Did load climb for 40 minutes before users noticed? Was the server completely healthy and the real problem somewhere else? Those answers often live in a separate monitoring product, disconnected from the incident timeline and disconnected from the status page. That is why I built Servers for StatusPage.me. It is a small, customer-installed host metrics agent and dashboard. You install it on a machine you operate, and it reports CPU, memory, swap, load, disk, and network metrics back to your account. The important part is not “now there are more graphs.” The important part is seeing an outage and the host evidence around it on the same timeline. External checks answer one question. Host metrics answer another. Regular uptime monitoring is still the right tool for the outside-in view: Can users reach the website? Is the API returning the expected response? Does DNS resolve correctly? Is the database port open? Did a scheduled job run? But those checks do not run inside your infrastructure. A healthy HTTP response does not prove that a background worker is about to run out of memory. A timeout does not prove that the app server is overloaded. And an incident can start with a slow disk or growing swap usage long before an endpoint is fully unavailable. The distinction is simple: External monitoring tells you what users can see. Host metrics help explain what the machine was doing when they saw it. You need both. What Servers includes Each registered host gets a dedicated dashboard page with: CPU user, system, and I/O wait utilization Memory use Swap use Load averages Disk use and read/write throughput Network inbound and outbound throughput A human-readable OS description for account owners Current values, historical charts, one-hour change, and small trend sparklines The dashboard has views from one hour to 30 days, subject to your plan’s retention. There is also a practical detail that matters during a real incident: if the server is linked to a StatusPage.me status page, the incident windows are shaded directly on its charts. That lets you answer questions like: Did memory climb before the API went down? Did the load spike end when the incident was resolved? Was the host normal while the dependency failed? Is this a recurring pattern or a one-off event? That is more useful than opening four dashboards, trying to align timestamps, and guessing. Threshold alerts without alerting on every spike Servers also supports threshold rules on plans that include Server Agent alerts. You can alert on metrics such as CPU, memory, swap, load, disk, disk I/O, and network throughput. More importantly, you choose how long a condition must hold before it fires. That duration is deliberate. A brief CPU spike during a deploy should not wake someone up. Sustained resource pressure probably should. The goal is not to turn every graph into another noisy alert source. It is to catch the conditions that are likely to become an incident before they do. The agent is open source because it runs on your production machines Asking someone to install an agent on a production server is a trust request. “Trust us” is not a sufficient answer. The Server Agent is open source: https://github.com/hosted-status-page/hsp-server-agent You can read the installer, the collector, the protocol, and the privacy documentation before installing anything. The dashboard generates a one-time installation command for each server: curl -fsSL https://statuspage.me/install-server-agent.sh | sudo bash -s -- \ --server-id \ --ingest-key You should read a script before piping it into sudo bash. That is true here, and it is true everywhere. The installer verifies the downloaded binary against a published SHA-256 checksum. It then installs the agent as a dedicated non-login system user, rather than leaving a root process running indefinitely. The resulting systemd service is deliberately restricted: No new privileges No Linux capabilities Read-only filesystem access except for its own local buffer Private temporary directory and devices Restricted system calls Memory and CPU limits The agent needs to read system counters. It does not need to be a foothold on your host. What data it collects By default, the agent collects one sample every 60 seconds and sends it outbound over HTTPS. A sample contains operational counters: CPU percentages Memory and swap usage Load averages Disk capacity and I/O throughput Network throughput Uptime Optional per-filesystem and per-interface breakdowns It can also report an operating-system description and an optional hostname. The hostname is optional because hostnames often contain a person’s name, internal project name, or other information you may not want to retain. You can send no hostname at all, and you can edit or clear it from the dashboard later. Authentication is per server. The agent sends a server ID and ingest key in request headers, not in the URL. On the server side, the ingest key is stored as a one-way hash rather than plaintext. What it explicitly does not collect This is the more important list. The agent does not collect: Process names or process lists Command lines Environment variables File contents User accounts Network peers Raw client IP addresses That is not just a policy statement. The wire protocol has a fixed schema. The ingest service rejects unknown fields instead of accepting arbitrary JSON and hoping it is harmless. There is no generic “metadata” bucket where process arguments, secrets, or application data can quietly end up later. You can inspect exactly what a host would send before configuring anything: serveragent -metrics serveragent -dry-run The first prints the collection policy. The second prints a real sample from the machine. What happens when StatusPage.me is unreachable? A monitoring agent that fills the disk during an outage is worse than useless. If the endpoint is unreachable, the agent keeps collecting metrics and stores unsent samples locally. When connectivity returns, it flushes them oldest-first. The buffer is bounded: by default, it holds up to 2,880 samples, or roughly 48 hours at the default cadence. At the limit, the oldest samples are discarded. That tradeoff is intentional. Losing old telemetry after a prolonged communication outage is better than turning the monitored host into the outage by consuming its disk. Samples are removed from the local buffer only after the server confirms they were stored, and ingestion is idempotent so retries do not create duplicates. On the server side, raw metrics are stored in time-partitioned tables, then rolled up for longer retention according to the account’s plan. Deleting a server removes its stored metrics. Uninstalling the agent removes its binary, configuration, service account, and local buffer. Public infrastructure health, without publishing your infrastructure Some teams want to show customers more than “all systems operational.” That is reasonable. But publishing a server name, hostname, IP address, or exact disk capacity is not. Servers can optionally expose a small Infrastructure section on a public status page when a host is linked to a component and the plan allows it. What is shown: The component name CPU percentage Memory percentage Disk percentage What is never shown: The server’s name Hostname IP address Operating-system details Absolute byte counts Internal capacity If the host stops reporting, it disappears from the public view instead of showing stale data. That is the boundary: show a useful operational signal, not an infrastructure inventory. This is not trying to replace every observability tool Servers is not a log platform. It is not distributed tracing. It is not a process profiler. It does not pretend to be a full observability suite. It is intentionally narrow. The job is to connect the status page, the incident timeline, and the host-level signals that help explain an outage. If an API fails while memory climbs steadily, that should be obvious. If the host is healthy, that should be obvious too. The product is available now in StatusPage.me. The source for the agent is here: https://github.com/hosted-status-page/hsp-server-agent And the full setup guide is here: https://statuspage.me/docs/servers/servers-monitoring