How to Fix Time Zone and NTP Sync Problems in Proxmox VE (Chrony, timedatectl, and Clock Drift)

If you have ever opened the Proxmox VE web interface and noticed the clock in the corner is off by a few minutes, or worse, your browser throws a certificate warning that makes no sense, the culprit is usually the same thing: the system clock. It sounds like a small detail. It is not. Proxmox leans on an accurate clock for more than just pretty graphs, and when it drifts, the symptoms show up in places that have nothing to do with time at all.

This guide walks through how Proxmox VE keeps its clock in sync, how to check whether it is actually working, and how to fix it when it is not. Everything here applies to a single standalone node just as much as it does to a cluster, though the stakes are higher once you have more than one node talking to each other.

What You Will Learn

• How Proxmox VE keeps its clock accurate, and which service does the work on your version
• How to check whether your node's time is actually synchronized (it might look fine and still be wrong)
• How to set the correct time zone from both the GUI and the shell
• How to point Proxmox at specific NTP servers, including internal ones for isolated networks
• What error messages and symptoms point back to a clock problem
• A short list of habits that keep this from becoming a recurring headache

What Is This Feature?

NTP stands for Network Time Protocol. It is the standard method computers use to keep their internal clocks synchronized with a trusted time source over a network, usually accurate to within a few milliseconds. Instead of relying on the cheap clock chip inside your server, NTP periodically checks in with a reference server and nudges the local clock toward the correct time.

Proxmox VE does this automatically out of the box using a background service. Since Proxmox VE 7, that service is chrony, a lightweight NTP client and server that ships enabled by default. If you are still running Proxmox VE 6, the job is handled by systemd-timesyncd instead, which is simpler but slower to correct large time offsets. Both do the same basic job: they compare the local clock against one or more remote time servers and adjust it, gradually rather than jumping the clock forward or backward in one violent step.

There is also the hardware side of this. Every server has a small battery-backed clock on the motherboard called the RTC, or real-time clock, which keeps ticking even when the machine is powered off. Proxmox expects that RTC to be set to UTC, not your local time zone. The time zone setting you configure in Proxmox is applied on top of UTC to display local time in the GUI, logs, and cron schedules — the RTC itself should stay in UTC.

Why Would You Use It?

You don't really "use" time sync the way you'd use a feature like snapshots or backups — it just needs to be working correctly in the background, all the time. But it's worth understanding why Proxmox cares so much, because the failure modes are confusing if you don't know the cause.

A few concrete examples of what breaks when the clock drifts:

• Cluster quorum. Proxmox clusters use a component called Corosync to keep nodes talking to each other and agreeing on cluster state. Corosync is sensitive to time differences between nodes — even a few seconds of drift can cause retransmits, and a large gap can knock a node out of quorum entirely.
• TLS certificates. The Proxmox web interface and API use HTTPS. If your system clock thinks it's yesterday, or next week, your browser will reject the certificate as "not yet valid" or "expired," even though the certificate itself is fine.
• Let's Encrypt / ACME renewal. If you use ACME to issue certificates for the web UI, certificate validation depends on accurate time. A skewed clock can cause renewal requests to fail for reasons that look nothing like a time problem in the error output.
• Backup and replication schedules. vzdump backup jobs, Proxmox Backup Server prune jobs, and storage replication all run on schedules and record timestamps. A wrong clock makes your backup history confusing and can throw off retention logic.
• Ceph, if you're running it. Hyper-converged Ceph clusters are just as picky about synchronized time across nodes as Corosync is.

Basically: get this right once, early, and you'll never think about it again. Ignore it, and you'll eventually spend an evening chasing a "cluster keeps losing quorum" ticket that turns out to be a five-minute clock fix.

Prerequisites

Before you start, make sure you have:

• A Proxmox VE node you can reach, either through the web GUI (typically https://your-node-ip:8006) or SSH
• Root access, or a user with enough privilege to run systemctl and edit files under /etc
• Outbound internet access on UDP port 123 if you're using public NTP servers — most homelabs are fine here
• If your Proxmox host is on an isolated or air-gapped network, the IP address of an internal NTP server you're allowed to use

You don't need any special packages installed. Chrony ships with Proxmox VE 7, 8, and 9 by default, so on any current install you're already set up to sync time out of the box — you're just verifying and adjusting it.

Step-by-Step Tutorial

1. Check what your clock is actually doing right now

Start by finding out if there's actually a problem, rather than guessing. SSH into your node and run:

timedatectl status

This is a standard systemd command that shows the current local time, the time zone Proxmox is using, and — the important part — whether the system clock is marked as synchronized. Look for a line that says System clock synchronized: yes. If it says no, something's wrong with your NTP setup and it's worth digging further before you do anything else.

Since Proxmox VE 7+ uses chrony, get more detail with:

chronyc tracking

This shows how far off your clock currently is from its reference source, in the System time line, along with which server chrony is using as its source. An offset of a few milliseconds is completely normal. An offset measured in seconds or minutes means something is actively wrong.

2. Set the correct time zone through the GUI

If your time zone is wrong (a common issue after installing from an ISO that defaulted to UTC, or when a server was shipped set to the wrong region), fix that first — a wrong clock and a wrong time zone look identical at a glance but need different fixes.

In the Proxmox web interface:

1. Select your node in the left-hand tree
2. Go to System > Time
3. Click Edit
4. Choose the correct time zone from the list and save

The change applies immediately — no reboot needed.

3. Or set it from the shell

If you'd rather do it over SSH, or you're scripting a node build, use:

dpkg-reconfigure tzdata

This opens an interactive menu to pick your region and city. Since Proxmox VE is built on Debian, this is the standard Debian way of setting the system time zone, and it updates the same underlying setting the GUI does. If you'd rather skip the menu entirely, you can set it directly:

timedatectl set-timezone America/New_York

Swap in whatever zone matches your location — you can list valid names with timedatectl list-timezones.

4. Confirm chrony is actually running

It's rare, but occasionally chrony gets disabled or masked, especially on nodes that were migrated or restored from an older backup. Check with:

systemctl status chronyd

You want to see active (running). If it's stopped, start and enable it:

systemctl enable --now chronyd

5. Point chrony at specific NTP servers

By default, chrony on Proxmox VE is preconfigured with a set of public time servers, which is fine for most setups with normal internet access. If you're on an isolated network, behind a strict firewall, or you just want to use your own internal time server (common in businesses that already run one for Active Directory), edit the chrony configuration file:

nano /etc/chrony/chrony.conf

Add or replace the server lines with your preferred sources:

server ntp1.example.com iburst
server ntp2.example.com iburst

The iburst option tells chrony to send a burst of requests right away instead of waiting for its normal polling interval, which gets you synced faster after a restart — there's basically no reason to leave it off. Save the file, then restart chrony to apply the change:

systemctl restart chronyd

6. Verify the new servers are being used

Give it a minute or two, then check:

chronyc sources -v

This lists every configured time source and how chrony currently rates each one. A source with a ^* next to it is the one currently selected as the primary reference. Sources marked with an x or showing a large offset are being rejected as unreliable — that's normal chrony behavior, not necessarily a problem, as long as at least one source is selected.

You can also tail the logs directly to watch it work:

journalctl -u chrony --since -1h

Commands Explained

Command	What it does
timedatectl status	Shows current local time, time zone, and whether the clock is marked synchronized
chronyc tracking	Shows chrony's current offset from its reference time source and which source it's using
chronyc sources -v	Lists all configured NTP sources and their current reliability rating
systemctl restart chronyd	Restarts the chrony service so config changes take effect
systemctl enable --now chronyd	Enables chrony to start on boot and starts it immediately
dpkg-reconfigure tzdata	Opens the standard Debian menu for setting the system time zone
timedatectl set-timezone <zone>	Sets the time zone directly without the interactive menu
timedatectl set-local-rtc 0	Tells the system the hardware clock (RTC) is in UTC, not local time
chronyc makestep	Forces chrony to immediately step the clock to the correct time instead of adjusting gradually

Common Errors

A few things you'll actually run into:

"System clock not synchronized: no" in timedatectl status output. This almost always means chrony can't reach any of its configured NTP servers — check your firewall and network route before touching anything else.

Browser certificate warnings on the web UI that mention the certificate is not yet valid or has expired, even right after a fresh install. This is a classic symptom of a clock that's off by days or more, not an actual certificate problem. Fix the clock first, then reload.

Cluster nodes randomly dropping out of quorum, with Corosync logs showing retransmit messages. Check chronyc tracking on every node in the cluster — one node with a bad clock is enough to cause this.

Large offset that never seems to correct itself. Chrony deliberately avoids making huge, sudden jumps to the clock once it's been running a while, since a sudden jump backward can break running services. If the offset is large (say, off by hours), a normal sync cycle can take a long time to gradually correct it.

Troubleshooting

If chronyc sources -v shows no usable sources, or every source has an x next to it, start with the basics: can the node reach the internet at all? Try ping 8.8.8.8 to rule out a general connectivity problem before assuming NTP itself is broken.

If general connectivity is fine but NTP specifically isn't working, check whether outbound UDP port 123 is being blocked somewhere between your node and the internet — a lot of corporate and cloud firewalls block this by default even when regular web traffic passes through fine. If you're behind a strict firewall, this is exactly the situation where pointing chrony at an internal NTP server (step 5 above) solves the problem cleanly.

If the clock is off by a large amount and you don't want to wait for chrony to gradually correct it, you can force an immediate step:

chronyc makestep

Use this sparingly. It's fine to run once after a fresh install or after fixing a broken NTP config, but jumping the clock while services are actively running can cause weirdness in anything that's timing-sensitive.

If a cluster node keeps drifting even with a working NTP source, double-check that you don't have both chrony and systemd-timesyncd installed and fighting each other — this can happen after certain manual package installs or migrations from older systems. Only one time-sync service should be active at a time.

Best Practices

A few habits that make this a non-issue going forward:

• Keep the RTC in UTC rather than local time. Run timedatectl set-local-rtc 0 if you're not sure which mode it's in — mixed-mode RTC causes real problems around daylight saving changes.
• On clusters, use the same NTP source configuration across every node. It doesn't have to be the exact same servers, but they should all be reachable and accurate — don't let one node sync against a different, less reliable source than the rest.
• For isolated or air-gapped clusters, run an internal NTP server rather than trying to work around the lack of internet access. It's a small amount of setup for a problem that otherwise never fully goes away.
• Don't manually set the date with date -s on a node that has a working NTP service. It's a fight you'll lose, and it can confuse chrony's drift tracking.
• After building a new node, check timedatectl status as part of your normal setup checklist, right alongside checking hostname and network config. It takes ten seconds and saves you a confusing debugging session later.

Frequently Asked Questions

Does Proxmox VE sync time automatically without me doing anything?

Yes, on a normal install with internet access, chrony is already running and syncing against public time servers out of the box. You only need to intervene if you're on an isolated network, want to use specific servers, or something has actually broken.

What's the difference between chrony and systemd-timesyncd?

Both sync your clock over NTP, but chrony is more capable — it handles larger time offsets faster and gives you more visibility with commands like chronyc tracking. Proxmox VE 7 and later use chrony by default; only PVE 6 relied on systemd-timesyncd.

Does the time zone setting affect cluster stability?

No — Corosync and other cluster components work in UTC internally. Time zone only affects how time is displayed in the GUI, logs, and local cron jobs. What actually matters for cluster health is that the underlying clock is accurate, not which zone you've set for display.

Do VMs and containers sync their own time separately?

Yes. Each guest OS manages its own clock sync independently of the Proxmox host — a Linux guest typically runs its own NTP client, and Windows guests sync against a domain controller or public time source. Installing the QEMU Guest Agent doesn't handle time sync by itself, so don't assume a correctly synced host means your VMs are automatically correct too.

My clock is off by exactly one hour. Is that an NTP problem?

Almost certainly not — that's a time zone or daylight saving mismatch, not a sync failure. Check timedatectl status for the configured zone before assuming chrony is broken.

Can I run an NTP server on Proxmox itself for my other devices to use?

Chrony can act as a server as well as a client, but for most homelab setups it's simpler to point your other devices at the same public or internal source Proxmox uses, rather than adding another layer to manage.

Conclusion

Clock sync is one of those things that's invisible right up until it isn't — and when it breaks, the symptoms rarely point straight back to the actual cause. A few minutes spent checking timedatectl status and chronyc tracking after setting up a new node, or whenever something in your cluster starts acting strange for no obvious reason, can save you a lot of confused troubleshooting later. Get the time zone and NTP source right once, and this is genuinely a "set it and forget it" part of running Proxmox.