Your service page has live graphs for CPU, memory, disk, and network. This guide explains what each one shows, and how to tell a normal spike from a problem that needs action.
1. Where the graphs are
In the client area, open your service and click Graphs under Service management. The same graphs are also in the control panel behind Log In To Panel, on the server's Graphs tab.
2. CPU
The CPU graph shows usage as a percent of your plan's vCPUs. Short spikes are normal; cron jobs, page builds, and updates all cause them. A problem looks different: the line stays near the top for a long time, and your app gets slow at the same moment.
To find the cause, log in and run top. The list is sorted by CPU use, so the process at the top is your answer.
3. Memory
The memory graph shows how much RAM the server uses, in MiB. Linux also uses free RAM for disk cache, so a high number is not always a problem. Inside the server, run free -h and look at the available column; that is the memory your apps can still get. If available stays near zero and processes get killed, you are out of memory: reduce what runs on the server, or upgrade the plan.
4. Disk throughput
The disk graph shows read and write speed in KiB. Big spikes during backups and updates are normal. If writes stay high all the time and the server feels slow, a process is hammering the disk. Run iostat -x 5 to watch disk load (install the sysstat package first), and check your database and log settings.
5. Network
The network graph shows traffic in both directions: Read is incoming traffic, Write is outgoing traffic. Steady daily waves are normal for a website. A flat line at a high level, at a time with no visitors, is worth a look: it can be a stuck process, a large transfer you forgot, or abuse.
The graph is not your traffic meter. Your traffic totals and limit are on the Networking tab in the control panel. Only outgoing traffic counts against your limit; incoming traffic is free.
Graphs show the whole server, not the cause
The graphs tell you which resource is under pressure. To find out which process causes it, log in and use top for CPU and memory, iostat -x 5 for disk, and ss -tnp for network connections.
6. Upgrade or investigate?
A simple rule: spikes are normal, plateaus are not. If a graph sits at its limit for hours while your workload has not changed, first find the process behind it. If the workload is real and simply grew, upgrade your plan from the client area under Actions, upgrade/downgrade.
Quick reference
| Graph | Normal | Needs a look |
|---|---|---|
| CPU | Short spikes | Long time near 100% plus a slow app |
| Memory | High use with cache | available near zero, killed processes |
| Disk | Spikes during backups | Constant high writes plus a slow server |
| Network | Daily waves | High flat line with no visitors |
Where to go next
If the graphs point at the disk filling up rather than disk speed, our full-disk guide walks you through freeing space. If a slow app is the complaint and the graphs look calm, the problem is usually in the app stack, not the server.