Resource Snapshot
Know what your machine is doing at this exact node in the graph
- passthrough
- passthrough
- cpu_percent
- ram_percent
- ram_used_bytes
- ram_total_bytes
- gpu_percent
- vram_percent
- vram_used_bytes
- vram_total_bytes
- gpu_temp_celsius
- gpu_available
- gpu_name
You're five hours into a batch and ComfyUI just crawled to a halt, or it OOM'd on the third image. Task Manager and nvidia-smi tell you what the whole machine is doing, but they can't tell you what was happening at the moment a specific node ran. That's the gap Resource Snapshot fills: it's a tiny node that freezes the machine's resource state into numbers you can read, wire, or log - right where it sits in your graph.
It ships in the Resource Monitor pack from PBandDev, which is mostly a live dashboard that mounts into ComfyUI's own chrome (Top mode in the workflow action bar, Bottom in the canvas toolbar, or a collapsed "Resources" button). That's the half people reach for first. The node is the part that behaves like a real node: it runs when the workflow runs, and it hands you scalars.
How it works
Under the hood the pack uses psutil for CPU and RAM, and nvidia-ml-py for GPU data - that's NVML, the same telemetry API nvidia-smi reads, so the GPU numbers come straight from the driver, not from guessing. On Windows it also pokes WMI to read the CPU's "Processor Utility" counter, which is why its CPU% lines up with Task Manager instead of drifting.
One detail worth knowing: the collector computes CPU% from its own sampled cpu_times() deltas rather than trusting psutil's module-level state. That sounds like nerdy plumbing, but it's the exact class of bug that makes naive monitors lie - there are threads about ComfyUI's built-in monitor showing 97% RAM when Task Manager says 63%. This pack deliberately dodges that.
If NVML isn't reachable - no NVIDIA card, an old driver, or a sandboxed environment - the GPU outputs don't error out; they just fall back to 0 and set gpu_available to false. You get gpu_name as an empty string. Graceful, and easy to spot in a log.
The inputs and outputs that matter
The input side is refreshingly boring: a single optional passthrough input that accepts any type and forwards it to the matching passthrough output. That's the whole trick for placing the node mid-chain - it can spy on a workflow without breaking a single wire.
Then it spits out a dozen scalars. The ones you'll actually touch:
cpu_percent,ram_percent,ram_used_bytes,ram_total_bytes- the CPU/RAM half (FLOAT and INT, respectively)vram_percent,vram_used_bytes,gpu_temp_celsius- the GPU half, plusgpu_available(BOOLEAN) andgpu_name(STRING) for knowing whether and what GPU is there
Honestly, this node is niche. The honest use cases: gate a workflow on available VRAM (if vram_percent is high, route to a lighter model or a tiled upscaler), or pipe these into a logging node to benchmark runs. For most people, the live monitor in the corner of the screen is the more useful half of this pack - the node is for when you want the workflow itself to be aware.
Install
Easiest path is ComfyUI Manager: open the Custom Nodes Manager, search for comfyui-resource-monitor, install, restart. Or the manual route:
cd ComfyUI/custom_nodes
git clone https://github.com/PBandDev/comfyui-resource-monitor
Then restart ComfyUI. The pack pulls in psutil and nvidia-ml-py automatically (plus WMI on Windows). One real gotcha: it declares requires-python >= 3.12. If your ComfyUI runs on an older embedded Python, this won't install - that's the thing to check first when Manager throws a fit.
Troubleshooting
- GPU values are all 0 /
gpu_availableis false. Your system isn't exposing NVML telemetry. Check the driver first; also common in containers or on laptops where the GPU is hidden from the OS. - The monitor doesn't appear after install. Restart ComfyUI and hard-reload the browser tab - frontend changes need the tab, Python changes need the server.
- Numbers look weird. Give it a couple of refresh ticks; CPU% is a delta between samples, so the very first read after startup can look off.
A resource monitor won't fix your OOMs - but knowing exactly where your VRAM died is usually the first step toward a workflow that doesn't.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| passthroughopt | * | — |
Outputs (12)
| Name | Type | Description |
|---|---|---|
| passthrough | * | — |
| cpu_percent | FLOAT | — |
| ram_percent | FLOAT | — |
| ram_used_bytes | INT | — |
| ram_total_bytes | INT | — |
| gpu_percent | FLOAT | — |
| vram_percent | FLOAT | — |
| vram_used_bytes | INT | — |
| vram_total_bytes | INT | — |
| gpu_temp_celsius | FLOAT | — |
| gpu_available | BOOLEAN | — |
| gpu_name | STRING | — |