Introduction

Open any node in Proxmox VE and click the Summary tab, and you're greeted with a wall of graphs. CPU usage, memory, network, disk read/write, something called "IO delay" — it's a lot to take in on day one, especially if you just came from a bare-metal server or a single VirtualBox VM where none of this existed.

Most beginners either ignore these graphs completely or panic the first time they see the memory bar sitting at 85% with only two lightweight containers running. Neither reaction is right. The graphs are genuinely useful once you know what each one is actually measuring, and a few of them measure something different than what you'd guess from the label.

This guide walks through every graph on the node and guest Summary tabs, what normal looks like, and where people usually get confused. By the end you'll be able to glance at a node and tell, in about five seconds, whether something needs your attention.

What You Will Learn

  • Where to find performance graphs for nodes, VMs, and LXC containers
  • What each graph actually measures, including the ones with confusing names like IO delay
  • Why the memory graph can look alarming on a perfectly healthy ZFS system
  • How to switch between the Hour, Day, Week, Month, and Year views and what each is good for
  • How to pull the exact same data from the command line with pvesh
  • When these built-in graphs stop being enough, and what people usually reach for next

What Is This Feature?

Every node, VM, and LXC container in Proxmox VE has a Summary tab in the web interface. It shows a set of time-series graphs built from data that a background service called pvestatd collects every few seconds — things like CPU load, RAM usage, network throughput, and disk activity.

That history is stored locally using round-robin databases, usually shortened to RRD. An RRD is just a fixed-size file that keeps recent data at high detail and automatically averages out older data instead of growing forever. It's the same technology tools like Cacti and MRTG have used for network monitoring since the late 1990s, and Proxmox uses it under the hood so you get real historical graphs without installing a single extra package.

You won't find a dedicated "Monitoring" menu for this — it's just part of the Summary tab for whatever object you've selected in the left-hand tree. Click a node, you get host-level graphs. Click a VM or container, you get graphs scoped to that guest.

Why Would You Use It?

The honest answer is: because it's already there. You don't need to install anything, open a firewall port, or maintain a separate service. Click a node, and you immediately see whether it's under memory pressure, whether the network link is saturated, or whether disk I/O is the thing making everything feel sluggish.

That makes it the right first stop for two very different situations. The first is routine health checks — a quick daily glance to confirm nothing is trending in a bad direction. The second is active troubleshooting, when a VM feels slow and you want to rule things in or out fast: is the host actually starved for RAM, or is this a network problem, or is a backup job hammering the disk right now?

Where it falls short is long-term retention and alerting. The built-in graphs don't send you an email when RAM usage crosses 90%, and the year view is too coarse to catch a five-minute spike from three weeks ago. That's the point where people usually set up an external metrics stack — but for a homelab or a small handful of production nodes, most people never need to go there.

Prerequisites

You don't need much for this one:

  • A working Proxmox VE installation you can log into via the web interface (this guide is written against Proxmox VE 9.x, but everything here has worked the same way since at least 7.x)
  • At least one VM or LXC container, running or not, so you have something besides the node itself to look at
  • Optional: SSH access to the node if you want to try the pvesh commands in the Commands Explained section

Step-by-Step Tutorial

Step 1: Open the node Summary tab

Log into the web interface at https://your-node-ip:8006, and in the left-hand tree, click your node's name (not Datacenter, not a specific VM). The Summary tab loads by default. If you've clicked away, it's the first tab across the top.

Step 2: Read the status row before the graphs

Above the graphs sits a small block of text: CPU model and core count, "Load average" (three numbers, following the classic Linux 1/5/15-minute convention), Uptime, and the Proxmox VE version. If Load average is climbing well past your core count, that's usually your first real clue something is CPU-bound.

Step 3: Understand the CPU usage graph

This graph shows the percentage of total host CPU capacity in use, averaged across all cores. On the node itself, 100% genuinely means every core is maxed out. It's a good early-warning graph, but it won't tell you which VM is responsible — for that you'd click into each guest individually and compare.

Step 4: Understand the Memory graph — and don't panic

This is the one that trips people up the most. On a node running ZFS, it's completely normal to see memory usage sitting at 80-90% even with almost nothing running. That's not a leak. ZFS uses a chunk of RAM as an ARC (Adaptive Replacement Cache) — a read cache that speeds up disk access — and by default it will happily grab up to half your physical RAM if nothing else needs it. Proxmox counts that cache as "used" in the graph, which looks scary until you know it'll shrink automatically the moment a VM actually needs that memory.

On a VM or container's own Summary tab, this same graph shows RAM usage relative to whatever you assigned that guest — not the whole host. If you gave a container 512 MB and it's sitting at 95%, that's the container running close to its limit, which is a completely different situation from the host-level ARC behavior above.

Step 5: Understand the Network graph

This shows inbound and outbound throughput, usually in bytes per second, for the interfaces attached to whatever you're viewing. On a node, that's the physical NICs and bridges. On a guest, it's just that VM's virtual network adapter. A flat line at zero on a guest that should be doing something (like serving files) is a fast way to confirm a network issue rather than an application one.

Step 6: Understand Disk I/O and IO delay

The Disk graph tracks read and write throughput. IO delay, shown only at the node level, is different — it's the percentage of time the CPU spent waiting on disk or storage requests instead of doing actual work. A quick spike during a backup job is normal. IO delay that sits high all the time, especially in the double digits, usually points at slow or overloaded storage, not a CPU problem, even though it shows up right next to the CPU graph.

Step 7: Switch time ranges

Above the graphs is a dropdown with Hour, Day, Week, Month, and Year. Hour is the one to watch live while you're actively debugging something, since it updates every 30 seconds or so. Day and Week are good for spotting patterns, like a backup job that reliably spikes IO delay every night at 1 AM. Month and Year get coarse fast — they're really only useful for confirming a general trend, like RAM usage creeping up over several weeks as you add more VMs.

Step 8: Compare a node's graphs to a guest's graphs

Click into one of your VMs or containers and look at the same set of graphs. You'll notice the node has IO delay and Load average, and the guest doesn't — those are host-level concepts and don't apply to an individual VM. Everything else lines up, just scoped down to that one guest's allocated resources.

Commands Explained

Everything above works from the browser, but the same numbers are available from the command line through pvesh, the shell interface to the Proxmox VE API. This is handy if you want to script a check or just confirm the GUI isn't showing you something stale.

pvesh get /nodes/pve/rrddata --timeframe hour --output-format json

This pulls the same hourly RRD data behind the node's Summary graphs, as JSON. Replace pve with your actual node name (check it with hostname if you're not sure).

pvesh get /nodes/pve/qemu/101/rrddata --timeframe day --output-format json

Same idea, but scoped to a single VM — swap 101 for the VM ID shown in the left-hand tree. For a container, the path is /nodes/pve/lxc/<ctid>/rrddata instead of qemu.

The --timeframe flag accepts hour, day, week, month, or year — the exact same options as the dropdown in the GUI. Run these as root over SSH, or with an API token that has read access to the node; a regular unprivileged user will get a permission error.

Common Errors

A few things people run into while poking at this feature:

  • Graphs show "no data" right after installing or rebooting. RRD needs a few data points before it can draw a line. Give it a couple of minutes and refresh.
  • Memory graph pinned near 100% with nothing obviously running. Almost always ZFS ARC, as covered in Step 4. Check arc_summary from the shell if you want to confirm it directly.
  • pvesh returns "permission denied" or a 401. You're either not running as root or your API token doesn't have the right privileges on that node's path.
  • Graphs stop updating entirely, on every object. This points at pvestatd itself, not any one guest. See Troubleshooting below.

Troubleshooting

If every graph on the node is flat or missing data, check whether the stats daemon is actually running:

systemctl status pvestatd

If it's not active, restart it:

systemctl restart pvestatd

It should come back within a few seconds, and graphs will start filling in again from that point forward — you won't get the missing history back, since it was never collected.

If only one guest's graphs look wrong while everything else on the node is fine, that's rarely a monitoring problem. Check that specific VM or container's status and logs instead of chasing pvestatd.

Seeing a gap in the graph right after a time zone change or a manual clock adjustment? That's expected — RRD is timestamp-based, and jumping the clock forward or backward confuses it. It sorts itself out once time moves forward normally again.

Best Practices

A quick daily glance at the Day view across your nodes catches more problems than you'd expect, and it takes about ten seconds per node once it's a habit.

Treat IO delay as your storage canary, not your CPU canary. If it's consistently elevated, look at your disks and storage backend before you start hunting for a runaway process.

Don't chase the memory graph on a ZFS host trying to get it "back down." That's fighting the cache doing its job. Judge memory pressure by whether VMs are actually getting starved, not by the percentage in that bar.

If you find yourself wanting alerts, longer retention, or graphs that combine multiple nodes on one dashboard, that's the signal to look at an external metrics setup rather than trying to force more out of the built-in graphs. Most single-node homelabs genuinely don't need to take that step.

Frequently Asked Questions

Why is my node's memory usage so high with barely anything running?

On ZFS systems this is almost always the ARC cache, which is designed to use available RAM and release it on demand. It's not a leak.

How far back does the history go?

The Year view keeps roughly a year of increasingly averaged data, thanks to how RRD stores it — recent data stays detailed, older data gets coarser automatically.

Can I get an email alert when CPU or RAM crosses a threshold?

Not from this feature directly. Proxmox VE's built-in notifications cover things like backup and replication job results, not custom resource thresholds — for that you'd need an external monitoring tool.

Why does a VM show 100% CPU when the host itself looks fine?

That percentage is relative to the vCPUs you assigned that VM, not the whole host. A single-vCPU VM pegged at 100% is using one core fully, which might be a tiny fraction of total host capacity.

Do these graphs cost any performance to run?

No, collection is lightweight and happens whether or not anyone's looking at the Summary tab. You're not turning anything on or off by viewing it.

Conclusion

The Summary tab isn't flashy, and it's easy to skim past it during your first week with Proxmox VE. But once you know that IO delay is about storage, not CPU, and that a full-looking memory bar on ZFS is often just cache doing its job, those graphs become one of the fastest ways to sanity-check a node before you go digging through logs. Give it a real look next time something feels off — there's a decent chance the answer is already sitting right there on the screen.