Usage and limits

Your hosting plan sets ceilings: how much processor time your websites may use, how much memory, how many processes at once. Most of the time you never meet them. This page is what happens when you do — and, more usefully, what was running

Written for: Customer, Reseller, Administrator

It is at Account → Usage and limits, and it is the answer to the most frustrating kind of support ticket there is: "the site was slow this morning and it is fine now."

The two halves of the page

What you use of what you may

Five bars, each with both numbers on it.

Bar	What it counts
CPU	processor time, as a share of your own ceiling, over the last hour
Memory	what your websites are using between them, right now
Processes	everything your account has running: PHP, cron jobs, your shell
PHP workers	how many pages your sites can build at the same time
Database connections	open connections of your busiest database login

Four of them read now. The CPU bar reads the last hour, and says so on the label. That is not an oversight: processor use only becomes a percentage once you compare two measurements, so a "right now" figure would be an invention.

A bar that says not measured is not a bar at zero. It means the server has not reported that number for this account — a database bar on a server with no database, for instance — and showing an empty bar instead would read as "nothing in use", which is a different thing entirely.

When you reached a limit

A counter per ceiling, a graph per hour, and a list of moments.

The counters and the graph answer how often. An hour with no bar is an hour in which nothing was refused; an hour with a gap is an hour nobody measured.

The list of moments is the half that closes tickets. When your account starts being refused, the server takes one recording of what is running: which processes, how much processor and memory each was using, how long each had been alive, and which of your database queries were open. Open a moment and you can see, for example, that wp-cron.php had been running for three and a half minutes and was holding half a gigabyte.

What is in a recording, and what deliberately is not

A recording is deliberately incomplete, and it is worth knowing where it stops:

A process is its program name, plus the path of the script it is running when that script is one of your own files. The rest of the command line is counted and thrown away, because that is where passwords and tokens get passed to programs.
A database query keeps its shape and loses its values. WHERE user_email='ann@example.nl' is written down as WHERE user_email=?, and numbers become N. You can see which query was slow; nobody can read your customers' data out of it.
Only your own account is in it. The recording is taken from your account's own process group, so a neighbour on the same machine cannot appear in it and you cannot appear in theirs.

Recordings are kept for as long as the graph beside them, and then removed.

"Your website was slowed down"

When your account has been stopped at a ceiling in the last few hours, a banner says so at the top of this page and on your account dashboard. It names the ceiling, because the three mean different things:

CPU ceiling — the server made your account wait. Visitors experience a slow website; nothing failed.
Memory limit — the server ended a process. Visitors get an error page instead of a website.
Process limit — the server would not let anything new start. Cron jobs and arriving visitors get an error.

What to do about it

There are exactly two ways out, and the right one depends on which ceiling.

Make it use less. A single plugin, a stuck cron job or a query with no index is the cause far more often than genuine growth. The recording names the process; start there.

Ask for more. If the recording shows ordinary traffic doing ordinary work, the plan is too small. Your hosting provider can raise the ceiling; the numbers on this page are the evidence for the conversation.

From the command line

If you have SSH access to the server, the same record is readable there:

# Everything your account was stopped at, newest first
corectl faults list --account youruser

# One moment in full: the processes, the workers and the queries
corectl faults show youruser-memory-1787…

For administrators: the same picture for every account

Monitoring → Usage and limits has three lists over the whole fleet:

Largest consumers, by processor time. The top of this list is usually healthy — a busy shop is what the platform is for.
Over 90% of a limit, by how close. This is the list that predicts tomorrow's ticket.
Accounts that reached a limit, by how often the platform said no. An account can top this list without appearing in either of the others: a small plan with a runaway cron job uses almost nothing and is refused constantly.

Every row opens that account's own page, which is where the recordings are.

You are also told without looking. An account that keeps being stopped raises an action required notification — not a critical one, because nothing is broken: the platform did exactly what the plan says it does, and a website is slower than its owner is paying for. One message a day per account. A process killed for running out of memory always reports, whatever the threshold is set to, because that account is not busy — it is broken.

The threshold is at Settings → Platform → Resource fault alarm, in faults per hour.