Something breaks in Proxmox VE — a backup job fails overnight, a VM refuses to boot, the web interface hangs — and your first instinct is to just reboot the node and hope it fixes itself. Sometimes it does. Most of the time it doesn't, and now you've also lost the exact evidence that would have told you what actually went wrong.
Proxmox VE doesn't hide this information from you. It's just spread across a few different places, and if nobody's shown you where they are, you can spend twenty minutes clicking around the web UI without finding anything useful. Once you know the three or four spots that matter, diagnosing a failed task takes under a minute.
This guide walks through exactly where Proxmox VE keeps its logs, how to read them from both the web interface and the command line, and what to do with what you find.
What You Will Learn
- The difference between Task History, the System Log tab, and journalctl — and when to use each one
- How to pull logs for specific services like pveproxy, pvedaemon, and corosync
- Where raw task logs and the web UI access log actually live on disk
- How to filter journalctl output by time, service, and severity so you're not scrolling through thousands of lines
- What a handful of common log messages actually mean
- How to stop the systemd journal from quietly eating your boot disk
What Is This Feature?
Proxmox VE doesn't write to one big log file the way some older Linux tools do. On a fresh Proxmox VE 9 install, almost everything logs through journald, the logging service built into systemd. Every Proxmox service — pveproxy, pvedaemon, pve-cluster, corosync, and the rest — sends its output there instead of to its own separate file. The one notable exception is the web UI's access log, which is written straight to disk.
You'll run into this logging system in three different forms, depending on where you're looking:
Task History is the list you see in the web UI of every job the Proxmox stack has run — backups, migrations, snapshots, VM starts, container creation, and so on. Each entry gets its own UPID (Unique Process ID), which is really just a long string encoding the node, the process ID, the user who triggered it, and a timestamp. Click any row and you get the full output of that specific job.
System Log is a tab you'll find under each node in the Datacenter tree. It's essentially a live-updating window into that node's journal — the same data journalctl would show you, rendered in the browser so you don't need SSH access to check it.
journalctl is the command-line tool for querying journald directly. It's the most powerful of the three: you can filter by service, time window, severity, or free-text search, and it isn't limited by however many rows the GUI decides to render.
Why Would You Use It?
Most beginners only go looking for logs after something has already gone wrong, and that's a reasonable place to start. A backup job fails at 3 a.m. and you want to know why before the next scheduled run tries and fails again. A VM won't boot and the GUI just shows a spinning task with no explanation. Two nodes in a cluster can't agree on quorum and you need to know if it's a network blip or something worse. Logs are also useful before anything breaks. If you're auditing who logged into your Proxmox host, or you want to confirm a scheduled backup actually ran last night instead of silently failing, the same tools apply. Here's the thing worth saying plainly: rebooting a node before you've checked its logs throws away your best chance at understanding the problem. Restarts clear a lot of the transient state that would have pointed you at the cause. Check first, restart second.
Prerequisites
- A working Proxmox VE installation (this guide was written against Proxmox VE 9.2, but the same tools apply to 8.x)
- SSH or physical/console access to the node for the journalctl sections — the Task History and System Log sections only need the web UI
- A user account with root privileges, or one assigned the Sys.Audit permission if you're not using the root account
- Basic comfort typing commands in a terminal — nothing advanced is required
Step-by-Step Tutorial
Checking Task History in the web UI
Log into the Proxmox VE web interface and click your node in the left-hand tree (or Datacenter, if you want to see tasks from every node in a cluster at once). Along the bottom of the screen you'll see a panel with tabs, and one of them is Task History. If you don't see the panel, look for the small arrow at the bottom edge of the window — it collapses sometimes.
Every row here is one job: a backup, a VM start, a template clone, whatever. The Status column tells you at a glance whether it finished OK or hit an error. Double-click any row to open the full log for that specific task — this is where you'll see the actual error message instead of just "failed."
A task's UPID looks something like UPID:pve1:00003A1F:0021B8CC:6893A2F0:vzdump:105:root@pam:. You don't need to memorize the format, but it's worth knowing the pieces: node name, process ID, start time, task type, the ID of the VM or container involved, and the user who kicked it off. If you ever need to find a specific task's raw log file on disk, this string is the key.
Reading the System Log tab
Still under your node, look for the System Log tab. This shows you a rolling view of that node's journal — general system messages, not just Proxmox task output. It's the right place to check when something feels wrong but you don't have a specific failed task to point at: the web UI feels sluggish, SSH connections are dropping, or you just rebooted and want to confirm services came up cleanly.
There's a "Since" field near the top where you can jump to a specific point in time, which saves you from scrolling through hours of noise. It's a reasonable stand-in for journalctl when you don't have terminal access handy, though it doesn't give you the same filtering power.
Using journalctl over SSH
For anything beyond a quick glance, SSH into the node and use journalctl directly. A few commands cover almost everything you'll need:
journalctl -u pveproxyShows log output from the pveproxy service, which handles the web UI and API on port 8006. If the web interface won't load, this is where to look first.
journalctl -u pvedaemonpvedaemon runs the privileged backend that actually executes tasks (starting VMs, running backups, and so on). If a task fails with a vague error in the GUI, the fuller explanation is usually here.
journalctl -u pve-clusterCovers pmxcfs, the cluster filesystem Proxmox uses to keep configuration in sync across nodes. Worth checking if the GUI shows a node as unreachable or configuration changes aren't propagating.
journalctl -u corosyncCorosync handles the low-level cluster communication that determines quorum. If nodes are dropping out of a cluster or you're seeing "no quorum" warnings, this is the log to read.
journalctl -fFollows the journal live, the same way tail -f works on a regular file. Useful when you're about to trigger something (starting a VM, running a manual backup) and want to watch what happens in real time.
journalctl --since "10 min ago"Limits the output to a time window instead of dumping the entire journal. You can also use absolute times, like --since "2026-07-20 14:00".
journalctl -p err -bShows only error-level (and higher) messages since the last boot. Good for a quick sanity check after a reboot without wading through informational noise.
Finding raw task logs on disk
Every task's full output is also stored as a plain file under /var/log/pve/tasks/. The directory structure is bucketed by the last two characters of the UPID to avoid dumping tens of thousands of files into one folder, so you won't usually browse it by hand — the Task History panel in the GUI is reading from exactly this location, so it's rarely faster to go digging here yourself.
The one file worth knowing about directly is the web UI's access log:
tail -f /var/log/pveproxy/access.logThis records every HTTP request hitting the Proxmox web interface and API, including the source IP. It's useful for spotting repeated failed login attempts or figuring out which client is hammering the API.
Checking VM and container-specific logs
For a QEMU virtual machine, start with the VM's own Task History (click the VM in the tree, then its Task History tab) to see start/stop/backup events. If a VM is refusing to boot and the task log doesn't explain why, journalctl -u pvedaemon around the same timestamp usually shows the underlying QEMU error — a missing disk, an invalid CPU flag, that sort of thing.
For LXC containers, the same Task History approach applies. If a container won't start, run pct start <vmid> directly from the shell instead of through the GUI — it prints the failure reason straight to your terminal instead of burying it in a task log.
Checking update and upgrade logs
If an apt update or apt full-upgrade went sideways, APT keeps its own history separately from journald:
less /var/log/apt/history.logThis lists every package install, removal, and upgrade with a timestamp, which is handy when you're trying to figure out exactly what changed before something broke.
Commands Explained
| Command | What it does |
|---|---|
journalctl -u pveproxy | Shows log entries for the web UI/API service |
journalctl -u pvedaemon | Shows log entries for the privileged task-execution backend |
journalctl -u pve-cluster | Shows log entries for the cluster filesystem (pmxcfs) |
journalctl -u corosync -n 50 | Shows the last 50 lines from the cluster communication service |
journalctl -f | Follows new log entries live, across all services |
journalctl --since "1 hour ago" | Limits output to the last hour |
journalctl -p err -b | Shows only errors and worse, since the last boot |
journalctl --disk-usage | Reports how much disk space the journal is currently using |
tail -f /var/log/pveproxy/access.log | Live-tails the web UI's HTTP access log |
One thing worth flagging: on older Debian-based systems it was common to also have a /var/log/syslog file you could grep through. On a stock Proxmox VE 9 install, journald is where nearly everything ends up by default, so don't be surprised if that file is missing or nearly empty. journalctl is the tool to reach for first, not a fallback.
Common Errors
A few messages come up often enough that it's worth knowing what they actually mean before you go searching.
TASK ERROR: command '/usr/bin/qemu-img convert ...' failed: got timeout — you'll see this in a backup or clone task's log. It almost always means the target storage was too slow, unreachable, or momentarily busy, not that something is fundamentally broken.
Failed to run vncproxy — shows up in pveproxy's log when the browser console can't connect to a VM. Usually a firewall or port issue rather than a problem with the VM itself.
[KNET ] link: host: 2 link: 0 is down — from corosync, seen via journalctl -u corosync. One node has lost its cluster network link to another. If it flaps repeatedly, look at the physical network path between those two nodes before you suspect Proxmox itself.
authentication failure; rhost=... user=root@pam — from pvedaemon or pveproxy. Sometimes it's just a typo in a saved script's password, sometimes it's someone probing your web UI from the internet. Worth checking the source IP in /var/log/pveproxy/access.log if you see a lot of these in a row.
Troubleshooting
When you're not sure where to start, work from specific to general. If there's a failed task in Task History, open it first — the error is usually right there. If nothing shows up in Task History but something still feels wrong, move to the System Log tab or journalctl and narrow the time window to right around when you noticed the problem.
If a whole feature seems down rather than one task — the web UI is slow, or backups keep failing across every VM — check more than one service. A slow GUI might trace back to pveproxy, pvedaemon, or even storage I/O, and cross-referencing timestamps across a couple of logs is often what actually reveals the cause.
If you're troubleshooting a cluster issue, check corosync and pve-cluster on every node, not just the one you're sitting on. A quorum problem on a two-node cluster, for example, can look completely different depending on which side you're viewing it from.
If the journal itself is misbehaving — taking forever to query, or your disk is filling up — check its size and trim it:
journalctl --disk-usage
journalctl --vacuum-time=7dThe first command tells you how much space the journal is using. The second deletes journal entries older than seven days, which is usually plenty for troubleshooting purposes on a homelab box. Swap in --vacuum-size=500M instead if you'd rather cap it by size than by age.
Best Practices
Check logs before you reboot, not after. It's tempting to restart a stuck service and move on, but you'll often lose the one piece of evidence that explains what happened.
Bound your journalctl queries by time. Running journalctl -u pveproxy with no filters on a node that's been up for six months will dump an enormous wall of text at you. Add --since and you'll actually find what you need.
If you're managing more than one or two Proxmox nodes, it's worth pointing them at a central log destination — something like Loki or a plain syslog server — so you're not SSHing into three different machines to piece together one incident. That's a bigger project on its own and outside the scope of this guide, but keep it in mind as your setup grows.
Keep an eye on journal disk usage, especially on nodes with small boot drives. It's not something that usually causes problems, but it's a five-second check that can save you a headache later.
Frequently Asked Questions
Where does Proxmox VE store its logs?
Mostly in the systemd journal, readable with journalctl or the System Log tab. Task History lives in the web UI and on disk under /var/log/pve/tasks/, and the web UI's access log is at /var/log/pveproxy/access.log.
How do I watch logs live as something happens?
Use journalctl -f from the shell, or open the System Log tab in the web UI, which updates automatically.
Why can't I find /var/log/syslog on my Proxmox host?
On a default Proxmox VE 9 install, almost everything logs to journald instead of writing directly to that file. Use journalctl in its place.
How long does Proxmox keep task history?
By default it keeps roughly the last 1,000 tasks per node before older entries age out. If you need longer retention, forwarding logs to an external system is the more reliable approach.
Can I view logs for just one VM or container?
Click the VM or container in the resource tree, then its own Task History tab — it filters automatically to just that guest's start, stop, backup, and migration events.
Do I need root access to view logs?
You need root, or an account granted the Sys.Audit permission on the relevant node. Regular VM-level users generally can't see node-wide logs.
Conclusion
None of this requires memorizing a dozen commands. In practice, you'll lean on three or four: Task History for a failed job, the System Log tab or journalctl -u <service> for a service acting up, and journalctl --since whenever you need to narrow things down to a specific window. Once you've used them a couple of times, checking logs stops feeling like a chore and becomes the first thing you do — before the reboot, not after.