Resource usage that shows what an account is actually doing

A CPU spike seen once is a clue, not a verdict. Resource Usage starts with a live account view of CPU, memory, task count, and the busiest processes, then connects that moment to historical data. The live panel refreshes regularly, so a user can see whether the workload is still active rather than chasing a screenshot from ten minutes ago.

The process list is built from the account's own system workload. It is useful for identifying a busy PHP worker, a Node.js process, or an unexpected command, but it does not expose the process table of other hosted accounts.

When did it happen?

Historical charts cover the resources most useful during an account investigation:

• CPU, memory and process count;
• disk space and inode usage;
• disk reads and writes.

Across the supported time ranges, these views reveal recurring patterns such as a nightly backup, a weekly import, or an application that gradually consumes memory until it is restarted.

Historical data is sampled operational evidence, not an invoice ledger. It is designed to explain account behavior and capacity pressure. The selected period and available samples remain visible so users know what the chart can and cannot prove.

Which process was there?

For CPU, memory, and process charts, SHM can retrieve the process snapshot nearest a selected timestamp. Instead of saying "memory was high at 14:32," the user can inspect which commands were present, their CPU and memory share, thread count, and resident memory around that minute.

Snapshots are bounded and account-scoped. If a sample is unavailable, SHM reports that fact rather than manufacturing a process list from the current moment and calling it history.

Disk space is only half the storage story

Disk Usage complements the charts with an account directory view that helps locate where space is going. Website files, logs, mail, caches, and old archives can have very different cleanup decisions, so a total alone is rarely enough. Inode usage matters too. A site can have free gigabytes and still struggle because millions of tiny files have exhausted available entries. Showing both storage and inode trends makes the limiting resource visible.

Change limits after the evidence

Resource Usage is most valuable before changing limits or blaming the application. A sustained workload may need more capacity. A single runaway command may need a code or job fix. Heavy writes at the same time every day may simply be a backup that should run elsewhere in the schedule.

SHM keeps the evidence close to the account and connects a graph to the processes behind it. That turns "the server felt slow" into a timestamp, a resource, and a much better next question.