The fleet at a glance

Servers → Monitoring answers the question you start the day with: is anything wrong, and if so where. It is not a wall of graphs and not a second server list — it is the top layer of everything your machines report about themselves, with the ones that need looking at sorted to the front.

There is a second tab under it: Usage and limits, about the accounts on those machines rather than about the machines. Both are below.

Four counters, and why those four

At the top sit four numbers about the whole fleet: how many servers are reporting, how many services are down, how many certificates expire within 21 days, and how many tasks have failed since the last measurement. That is a small set on purpose: it used to be nine columns in one wide table, and the question "is anything wrong?" was answered by reading forty rows.

Under the counters are the machines, the worrying ones first. A row opens the server's own page; the table does not try to carry every fact about a machine, because that is what the page is for.

Every row says when it was taken

Both halves read from the panel's own store rather than from two hundred machines at once. That is not thrift: two hundred live scrapes take as long as the slowest of them and fail the moment any one machine is down. So every row carries the moment it was taken, and the top of the page says how often sampling happens — or that sampling is switched off.

If you want a fresh reading now there is Read again. It re-reads the servers; it is the same thing the clock does, on your say-so.

The version inventory

Below the machines is what is installed across the whole fleet, per package: which version is in use, how many servers are behind, and which have not been read yet. A server that is not in here is not broken — it has not been read yet, and its catalogue appears as soon as you open its page. From here you step across to the rollouts when something needs updating.

Usage and limits: three lists, not a table

The second tab is about accounts, and it is three separate lists because they are three questions with different answers:

• Who is using the machines — by processor time actually spent. The account at the top is usually a healthy one: a busy shop is what a hosting platform is for. This list is for capacity planning, not for pointing at somebody.
• Who is nearly at a ceiling — how close an account is to one of its own limits. This is the list that predicts tomorrow's support ticket.
• Who keeps being stopped — how often the platform actually said no. An account can top this list without appearing in the first one: small plan, small ceiling.

Each row says which limit was hit — throttled on CPU, memory refused, processes killed, process refused — over the period you choose above the lists.

When you want to hear it from a server itself

What the panel shows comes from the agent on each machine. To ask at the source — because a row is older than you expected, say:

# One machine's full checklist, with a severity and a category per row
ssh root@srv1.example.com 'corectl doctor'

# And re-measure what is due (--force measures everything, now)
ssh root@srv1.example.com 'corectl advisor refresh'

See also

• Reading the server advisor — the same checks, per machine and with the reasoning attached.
• What the panel knows about itself — the machine that runs no agent.
• Rolling servers out in waves — where the version inventory leads.
• Usage and limits — the same subject, seen from one customer.