Monitoring that goes inside the server.
External checks tell you the site still answers. A small push agent adds CPU and memory from inside the server, so you see trouble building.
Outages usually announce themselves first, from the inside.
Before the 502s start, memory creeps up for an hour. Before the timeout page, one process pins a core. From the outside, everything looks fine right up until it does not.
Server metrics put those numbers next to your uptime checks. When an incident does open, the CPU and memory history from the minutes before it is already on the same screen, instead of in an SSH session you have to go open.
Push-based, so your firewall stays closed.
Most server monitoring wants an open port or a heavyweight daemon with root and an auto-updater. This is the opposite: your server makes one small outbound HTTPS request per sample, and that is the entire protocol.
Works behind NAT, in a private subnet, or on a box whose security group allows nothing inbound. If the machine can reach the internet, it can report.
# a cron entry and four numbers: a complete agent * * * * * /opt/scripts/report-metrics.sh # report-metrics.sh curl -fsS -X POST \ "https://uptime-status.org/api/agent/$METRICS_TOKEN/metrics" \ -d cpuPercent=42 -d ramPercent=71 \ -d ramUsedMb=5816 -d ramTotalMb=8192
What server monitoring includes.
- Push, not pull your server makes an outbound HTTPS request. No inbound port, no firewall rule, no daemon listening for us.
- CPU utilization a CPU percentage with every sample, so a runaway process shows up as a climbing line, not a surprise outage.
- Memory usage RAM as a percentage plus used and total megabytes, the numbers you would otherwise SSH in to look at.
- One history for everything samples land in the same per-monitor history and charts as your checks, next to uptime and incidents.
- A token, not credentials each server pushes to its own URL with an unguessable token. Malformed samples are rejected with a clear error.
- Any agent you like the endpoint is plain HTTP. A curl line on a cron schedule is a complete agent; so is your own script or tool.
Most uptime tools stop at the network edge.
Oh Dear, for one, offers no server metrics at all: the inside of the machine is your problem. UptimeStatus treats the host as part of the same story as the endpoint, in one dashboard, on one incident timeline. See the full comparison for the feature-by-feature view.
Server monitoring, answered.
Do I have to open a port on my server?
No. The agent pushes metrics out over HTTPS to your monitor's endpoint. Nothing connects inbound, nothing listens, and servers behind NAT or a strict firewall work without any network changes.
Which metrics are collected?
Each sample carries CPU utilization as a percentage, memory utilization as a percentage, and memory used and total in megabytes. Samples are validated on arrival and timestamped into the monitor's history.
What is the agent, exactly?
Anything that can make an HTTP POST. A short shell script on a cron schedule or systemd timer is enough: read the numbers from the OS, POST them to your metrics URL. There is no required binary and nothing to keep patched.
How often should I push?
As often as you want the resolution. A sample every minute is a sensible default and costs one small outbound request; the cadence is entirely under your control since your side does the pushing.
What if a server stops reporting?
Pair the same box with a cron heartbeat monitor: the metrics script pings it on every run, and silence past the grace period opens an incident. That way a dead agent, a wedged host, or a lost network path all surface the same way.
Is the metrics endpoint secure?
The URL contains an unguessable random token that acts as the credential, the same convention as heartbeat pings. Keep it in an environment variable rather than a public repo, and out-of-range values are rejected before they touch your history.
Pairs well with.
Cron monitoring
The natural partner: a heartbeat on the metrics script alerts you the moment a server goes silent.
Learn morePing monitoring
ICMP reachability for hosts and network gear, the outside-in view of the same machines.
Learn moreTCP port monitoring
Watch the ports your services actually listen on: databases, mail, SSH, anything with a socket.
Learn moreStart monitoring in under 2 minutes.
No credit card required for the self-hosted, open-source version.