How to Monitor CPU, RAM and Website Health on Ubuntu

Separate availability, capacity and freshness

A server can answer ping while a website fails. A service can run while its database connections are exhausted. A dashboard may contain an old sample. Record what was checked, when, and which part of the request path the result covers.

Begin with the affected URL, time and symptom. Compare application behavior with host and service evidence from that interval. “A specific request timed out” is a more useful incident than “the server is slow.”

Collect a read-only baseline

These commands inspect load, memory, disk and high-CPU processes; they do not change configuration. Permissions and installed tools vary. Output can contain operational identities, so redact it before sharing.

uptime
free -h
df -h
ps -eo pid,user,%cpu,%mem,comm --sort=-%cpu | head -n 15

Trace pressure to a workload

Load needs context: runnable work, I/O waits and database activity can produce different patterns. Inspect the relevant service and application rather than restarting everything. Low CPU does not exclude a full PHP pool.

Use Apache or PHP-FPM status only where configured and restricted. Do not publish diagnostic endpoints. EzePanel’s Server Health and Monitoring offer connected evidence, but sample freshness and check scope still matter.

Verify the user-visible result

After a supported action, repeat the failing request and its critical dependencies. Preserve incident context so another administrator can understand what changed. A successful service action is not a complete application test.

Controlled Recovery applies only to eligible supported actions. If safety checks or verification fail, human review is required. Keep an external availability check: monitoring on the affected host can lose visibility when the host itself fails.

Collect a repeatable baseline

Use the same observations in healthy periods and incidents. These read-only commands show load, memory, filesystem blocks and inodes. They do not explain cause alone. Keep several samples and the incident time rather than treating one screenshot as a trend.

Load average is not a CPU percentage. It includes runnable and some waiting tasks, so storage pressure can affect it. A full filesystem can fail application writes even when CPU and RAM look comfortable.

uptime
free -h
df -h
df -i
vmstat 1 5

Pair telemetry with a user journey

A running process does not prove a website works. Request the actual domain, check content and exercise an authorized application action. Separate cached pages from PHP/database requests. Verify a real mailbox path separately when email is in scope.

EzePanel freshness and service evidence help distinguish healthy samples from stale information. A new server may have no tenant PHP socket or website log sample. That is not a successful measurement of tenant traffic.

Make alerts actionable

A useful alert identifies the affected service, evidence and sustained condition to investigate. Brief transitions and persistent outages need different treatment. A process existing is not a reason to suppress a repeated failure.

Define the recipient and first diagnostic step. After repair, record user-visible recovery and follow-up. Monitoring should shorten diagnosis and demonstrate whether the repair worked, rather than merely increase the quantity of collected numbers.

Correlate host metrics with an actual website symptom

CPU percentage, memory pressure and a website response answer different questions. Start with the reported symptom and timestamp, then inspect related processes, account policy and service evidence. A low system load does not rule out a slow external API or database lock.

Use EzePanel’s available host and account views together, checking snapshot age and collection scope. If a metric is unavailable, preserve that distinction instead of interpreting it as zero. Validate the application action that customers reported; a running service alone does not prove that action works.