How server monitoring works

Everything else UptimeCraft does is done from the outside: we ask your site for a page and see what comes back. The agent is the opposite. It runs on your own server and reports what only something inside the machine can see — how full the disks are, how much memory is actually available, how long it has been up.

Server monitoring is available on the Business plan.

What it is

A single Go binary, around 6 MB, with no runtime to install. It runs as its own unprivileged user under systemd, takes a reading every ten seconds, and sends a summary every minute.

That gap between sampling and reporting matters. Each report carries the lowest, highest and average value for every minute, so a spike that lasted twenty seconds is still visible to us. If the agent sent one instantaneous reading per minute, a server that briefly pinned its CPU would look unremarkable — and that is precisely the minute you want to know about.

What leaves your machine

Numbers, and almost nothing else. A report contains:

• the agent's version and the checks it is able to perform;
• for each check: the minimum, maximum and mean for each minute, and how many samples went into them;
• for disk checks, the mount point the number refers to;
• the list of filesystems the machine has mounted, with the filesystem type and whether each is read-only, so we can work out which are worth watching;
• a hash of the machine's identity (see below), and the agent's own clock, which we record and compare but never trust.

It does not send file contents, process lists, command output, environment variables, logs, or anything typed by a person. When configuration checks arrive in a later version, they will send a named set of fields that each check declares — never the file itself.

What it reads

On Linux, only these, and only for reading:

It cannot run commands

The agent accepts no commands, and this is a property of the program rather than a promise we are making. There is no code in the binary that executes anything — no shell, no process spawning, nothing.

What we send it is a list of checks it already knows how to perform, each named by a key like host.disk.used_percent with a parameter saying which mount to look at. If we sent a key the agent does not recognise, it reports that it cannot do it and carries on. There is no mechanism by which we could ask your server to do something the installed version was not already built to do.

This is deliberate and permanent. "Restart this service for me" would put remote code execution on every customer's servers and make us a supply-chain target. If you need that, you need a configuration management tool, not a monitoring agent.

How it identifies itself

Two credentials, with deliberately different powers.

An enrollment token is what you paste into an install command, a cloud-init block or an Ansible play. It can create a server and nothing else: it cannot read your metrics, see your other servers, or touch your monitors. That narrowness is what makes it safe to put in configuration management. It expires — by default after 24 hours.

A per-server key is minted when a machine enrols, belongs to that one machine, and is stored only as a hash so we could not tell you what it is. It rotates automatically, riding along with a report the agent was making anyway. You never deal with it.

The machine also sends a hashed fingerprint of its own identity. We use it for one thing: telling a restored backup from a copy. A restored snapshot goes quiet and comes back as the same machine. A clone reports at the same time as the original — and rather than silently merging two servers' numbers into one graph, we hold the newcomer and ask you.

What it costs the machine

The systemd unit caps it at 128 MB of memory and 10% of one CPU. In practice it uses a fraction of that: reading seven numbers out of /proc every ten seconds is not work. If it ever approaches those limits, something has gone wrong and we would rather it be stopped than slow your server down.

Outbound only

The agent opens an HTTPS connection to https://dev-api.uptimecraft.com and nothing listens on your machine. There is no port to open in your firewall and no inbound rule to write. That is also what makes it installable inside networks where nothing else will ever be opened.