Read the CPU, RAM and disk graphs in the panel
What the Usage card on your server's Overview is actually telling you, which shapes are normal, and which ones mean you need to act.
6 min read · Updated Oct 21, 2026 · By GuavaHost Team
Sign in at customer.guavahost.com, open My servers, click Manage on your server and look at the Usage card on the Overview tab. It shows live CPU, RAM and storage, and View history opens a graph of the last few minutes. Those three numbers answer most "is my server struggling?" questions, once you know what each one measures.
CPU
The CPU reading is how hard your server is working the processor it has been given. It is the number that matters most for lag, because game servers are almost always processor bound rather than memory bound.
Two things make it harder to read than people expect.
First, most game servers do the important work on a single thread. A thread is one line of work the processor runs at a time, and the main game loop is one of them: the world tick, mob movement, redstone, player actions. Extra cores help with world saving, chunk loading and plugins that run their own threads, but they cannot share that main loop. So a server can feel awful while the overall CPU number looks unremarkable. Why single thread performance matters goes into this properly.
Second, the number is a share, not a speed. What matters is not the exact figure but whether it is pinned at its ceiling and staying there. Brief trips to the top are normal. A flat line along the top for minutes on end is your bottleneck.
A healthy CPU graph looks like a heartbeat: a tall spike while the server boots and loads the world, then a lumpy baseline that rises with player activity and falls back when things calm down.
Worth acting on: the line sits at its ceiling whenever players are online and the game feels slow with it, it sits high with nobody online (usually a plugin, mod or scheduled task working in the background), or it climbs over hours and only a restart brings it down.
For the first two, the real measure of whether players will feel it is the server's tick rate, not the CPU percentage. Reading TPS and MSPT shows you how to check that, and why is my server lagging is the full diagnostic path. If the CPU looks high and nothing you run explains it, CPU steal and noisy neighbours covers the case where the cause is outside your server.
RAM
The RAM reading is how much memory your server uses out of the amount your plan allows. It is the graph people misread most, because on a Java game a high number is the design, not a warning.
Java runs inside a virtual machine handed a maximum heap (the pool of memory it may use). It does not return memory the instant it is finished with it. It fills the pool, runs a garbage collection pass to clear what is no longer needed, then fills it again. On a graph that is a sawtooth: a climb towards the limit, a sudden drop, another climb.
So for a Minecraft Java, Valheim or Terraria server:
- Sitting at 80 to 95 percent of the limit most of the time is normal.
- A sawtooth shape is normal and healthy.
- What is not normal is the number welded to the limit with no drops at all, plus a stuttering server and
OutOfMemoryErrorin the log.
That combination is the real out of memory signal. Signs your server is running out of RAM lists the symptoms and Java heap space errors covers the message. If the collection pauses themselves are the problem, Aikar's flags are the standard fix.
Games that do not run on Java, such as Rust, Palworld, ARK and CS2, behave differently. Their memory use climbs as the world grows and players spread out, and it should plateau rather than ride the ceiling. One that creeps up all session and never falls is worth a scheduled restart; see scheduling automatic restarts.
If you genuinely need more, you can change the amount at any time from Manage plan, and it is prorated. Changing your server RAM has the steps, and how much RAM do I need helps you pick a number.
Storage
Storage is how much disk your server's files take up. It moves slowly, which is why people ignore it until it bites.
A full or nearly full disk is nastier than a busy CPU because the server cannot write. In practice that means:
- World saves fail, so hours of play can vanish on the next restart.
- The log stops being written, so you lose the error that would have explained the problem.
- Backups fail, because a backup needs space to build the archive.
- A crash loop about not being able to write a file, which looks like a corrupt install but is not.
What eats disk, in rough order: a huge world, old logs and crash reports, world copies you saved into the server itself, and leftover modpack downloads. Players exploring in a straight line generate world data fast, which is why chunk loading and pregeneration matters on a big map.
Two habits keep it under control: clear old logs and crash reports off the Files tab now and then, and keep backup copies out of your server's own files. Backups taken on the Backups page already live elsewhere, and off-site backups keeps a copy somewhere else again.
Putting the three together
Compare what the card shows with what players report.
| What you see | What it usually means |
|---|---|
| CPU pinned, RAM normal, players lagging | Too much work per tick: entities, plugins, redstone, view distance |
| RAM pinned flat with no drops, stuttering | Genuinely out of memory, or a leak |
| Both normal, players still lagging | Not the server: distance, their connection, or ping |
| Storage near full | Fix this first, before anything else |
| Everything normal, server keeps restarting | Read the log, not the graphs |
That third row catches people out. If the server reads healthy, the delay is the trip between your players and the machine rather than the machine itself, which is lag versus ping.
Reading the history graph
View history is best used as a before and after. Note the shape, make one change (lower the view distance, remove a plugin, add RAM, turn on a nightly restart), then look again with a similar number of players online. The graph covers a short recent window, so it is a tool for watching a change land rather than long term record keeping.
One more trick: watch a start. A clean boot has a CPU spike, a RAM climb and then a settle. If the settle never arrives and both stay high with nobody connected, something is looping, and the Console tab will usually name it.
Common questions
Why is my RAM always at 90 percent?
On a Java based game that is normal. Java fills the memory it is allowed, then clears it in one pass, so it tends to sit high and drop sharply. Worry only if it stays pinned with no drops and you see out of memory errors in the log.
Is high CPU bad?
Only if it stays at its ceiling while the game feels slow. Spikes during a start, a world save or a burst of activity are how a healthy server looks. The useful second check is your tick rate, which tells you whether players are actually affected.
My disk is nearly full, what can I delete?
Old log files and crash reports are the safe wins, and often the biggest. After that, look for world backups or modpack archives saved into the server folder itself and move those off the server. Never delete the world folder your server is currently running.
Do the graphs show history from last week?
No, the history view covers a recent window rather than a long archive, so it is for watching a change take effect rather than long term reporting. If you need to compare across days, note the numbers down yourself at the same time each day.
Still stuck? Jump into our Discord at discord.gg/GuavaHost and the team will help you out.
- panel
- performance
- ram
- cpu
- monitoring
Still need help? Our team is online 24/7 to answer questions.