Server metrics and alerts

Server metrics and alerts show you what each server has been doing — CPU, network, disk and more — as graphs, and can notify you when something stays wrong for too long. This is for anyone who wants to keep an eye on server health without watching charts all day.

#Overview

• Every server gets live CPU, network and disk graphs automatically, once monitoring is switched on for it.
• Memory, disk space and load average need the InfraNest agent installed, because your provider's connection doesn't report them.
• Alerts are pre-built for you — there's nothing to create from scratch, just numbers to adjust if needed.
• InfraNest also points out what looks unusual, and offers a likely reason why.

#See the metrics

1. Go to Monitoring → Servers to see every server at a glance.
2. Open a server to reach its own monitoring page, with live CPU, network in/out and disk read/write graphs, plus disk space and what is running.

NoteA server has to have monitoring switched on before anything is collected about it. Memory, disk space and load average only appear once the agent is installed — your provider simply doesn't report them.

#Read the Metrics tab

1. Open a server and choose Metrics.
2. Pick a time range at the top: 5 minutes, 1 hour, 12 hours, 24 hours, 7 days or 30 days.
3. Read What stands out in this period first — it lists up to three things worth your attention, such as a metric past its alert line, a level that's unusually high for this server, or a change that lines up with a deploy or restart.
4. Use Compare with to draw a second, dashed line: Same time last week, or another server with a similar role.
5. Hover over any chart — all the others follow, showing their value at that same moment.
6. Tick or untick Events, Alert lines and Normal range to show or hide those overlays.

#See what is unusual, and why

1. Open a server and choose Unusual.
2. Review the list of things that don't match the server's normal pattern, each with a small graph.
3. Check what InfraNest says came just before it — marked Known cause, Likely, or Seen together, cause unclear.
4. Answer Yes or No, something else under Is this the cause? to teach InfraNest for next time. Pick None of them if nothing fits.
5. Use Show on the chart or Alert before it gets worse if you want to act on a finding.

#Silence a server while you work on it

1. Open the server from Monitoring → Servers.
2. Click Silence 1h, or open the ⋯ menu beside it and choose 4 hours or 24 hours for longer work.
3. Click End silence on the server's page, or choose it from the row's ⋯ menu, to stop early.

NoteA silence ends by itself — there's no way to silence a server forever. Rules keep being checked and charts keep updating; only notifications are held. If something is still over a limit when the silence ends, you're told then.

#Set up an alert

1. Go to Monitoring → Alert defaults and switch on the alert you want. It saves immediately and every monitored server follows it.
2. To give one server different numbers, open it from Monitoring → Servers, go to its Alerts & rules tab, click the threshold or the minutes in the sentence under the alert, type a new value, and press Enter or click away.

The duration is a window we average over, not a stopwatch, so a one-minute spike won't trigger it. Once an alert fires, the metric has to drop clearly below your limit before it's marked recovered.

#Check a threshold against the last 30 days

1. Open a server's Alerts & rules tab.
2. Review each alert's last 30 days — how many times it would have fired, how many times it actually did, and the highest value reached.
3. If every firing happened at the same time, such as every Sunday at 03:00, click Add a maintenance window for that time Pro to quiet it going forward.
4. If the card suggests a better number, click Use to apply it straight away.

For disk space, consider clicking Switch to a forecast alert to be warned based on the date the disk will be full, rather than a percentage that warns too early or too late.

#What you'll be sent

You get at most two messages per alert: one when it fires, and one when it comes back to normal. A spike too short to trigger the alert sends nothing at all — not even an all-clear.

NoteThese incidents live alongside your uptime-monitoring incidents, so server health and service uptime show up in one place.

#If you install the agent

Nothing about thresholds, durations or notifications changes — you simply get more metrics to write rules about, readings every minute instead of every five, and the option of an alert for a server that stops reporting entirely. The agent also reports pending security updates, whether a restart is needed, and the server's real CPU, memory and disk size.

#When a service fails, we tell you why

If you've installed the agent, the Services tab lists what runs on the machine and puts anything failed at the top, with a plain-language reason — for example Ran out of memory, Stopped with an error, or Crashed.

If you've switched on the failed-service alert, you'll be messaged with the service name and server. When every watched service is running again, the same destinations get a message saying so.

#Ignore a service you do not care about

1. Open the server's monitoring page and go to the Services tab.
2. Under Needs attention, find the service and click Ignore.
3. To resume alerting on it later, find it under Ignored on this server and click Stop ignoring.

#See the containers on a server

If a server runs Docker or Podman, the Services tab also lists its containers, with how long ago each started, how many times it has restarted, and how much memory it is using. Containers are listed by their short ID rather than their name, since the agent never connects to Docker itself.

#See why a service failed, from the system log

1. Open the server, go to System, and under What the agent reads here find Why a service failed, from the system log.
2. Click How to turn it on, copy the command, and run it on the server.
3. Within a minute the row says On.

From then on, a failing service shows its last few log lines on its problem card — masked for passwords and keys, and kept for 30 days. Login records and full logs are never sent.

#Troubleshooting

• A rule looks greyed out on a server — that metric (memory, disk space, load average) needs the agent installed; it can't be measured through your provider's connection alone.
• Something private appeared in a service's log lines — click Something private got through? Remove these lines under them and confirm. Change any exposed password too.
• You removed the last agent token — the server goes straight back to provider-only metrics, and any rule that only the agent could measure stops being measured.

TipUse Silence 1h (or longer) instead of turning off an alert when you're doing planned maintenance work that will temporarily look like a problem — it ends by itself, so you can't forget to turn it back on.