Bitcoin Nodes & Infrastructure

Bitcoin Node Clock Wrong? How Time Sync Affects Your Node

Jul 11, 2025 · 19 min read · Updated Latest correction
Two identical unmarked analogue desk clocks show different hand positions on charcoal canvas.

Short answer: Bitcoin Core checks block timestamps against your computer’s own clock. If that clock runs more than two hours behind, the node rejects new blocks as being from the future and stops short of the current block height. Since version 28 it also warns you when your clock is more than 10 minutes out of step with its peers. Fix the clock with NTP, then restart the node; the steps below show how, and the background follows them.

A timeline of real time from 3 hours ago to 2 hours from now. Top row, your clock is right: your node lets through timestamps up to 2 hours ahead of your clock (the band that passes the two-hour rule), so a new block mined now falls inside it and is accepted. Bottom row, your clock is 3 hours behind: the window ends 2 hours after your clock, which is 1 hour ago, so the same block mined now falls outside it and is rejected as time-too-new. More than 2 hours behind, every new block looks like it comes from the future: the node stops at its last block and waits. It stalls; it doesn't fork.
A clock that runs behind shuts out new blocks. Your node accepts a block only if its timestamp is at most 2 hours ahead of your own clock. With the clock 3 hours behind, a block mined right now is rejected and the node stops at its last block.

Step-by-Step Guide

Diagnosing and resolving time synchronization problems on a Bitcoin node requires checking multiple system layers. These steps walk through the entire process from identifying a time-related issue to confirming your node is operating with accurate time.

Three setups side by side, each a chain from NTP servers down to Bitcoin Core. On its own machine: NTP servers, then the NTP service (chrony, ntpd or timesyncd), then the system clock, then Bitcoin Core, which reads that clock. In a Docker container: the NTP service and the clock belong to the host, and Bitcoin Core inside the container reads the host's clock. In a virtual machine: the VM has its own clock, which drifts more easily, so the NTP service and the VM's guest agent run inside the VM. In each setup the NTP service is marked as the place to fix the time. Bitcoin Core never sets the clock; it only reads it, and an NTP service inside a container can't set it.
Fix the time where the clock is kept. Bitcoin Core only reads the clock. On its own machine that means the machine’s NTP service; in Docker, the host’s; in a virtual machine, the one inside the VM.
  1. Check Bitcoin Core’s reported time offset

    Open the Bitcoin Core Debug Console or use the command line: bitcoin-cli getnetworkinfo. Look at the timeoffset field: it is the median, in seconds, of the time offsets reported by your outbound peers, and a positive value means their clocks are ahead of yours. A value between -5 and +5 seconds is normal, but an exact 0 can also mean the node has not yet heard from five outbound peers, the minimum Bitcoin Core needs before it calculates the median. Since version 28, Bitcoin Core shows a warning, in debug.log and in its warnings field, when that median is more than 10 minutes. bitcoin-cli getpeerinfo shows the offset of each peer.

  2. Verify your system clock against an external reference

    On Linux, run timedatectl status to see the current system time, timezone, and NTP synchronization status. Compare the displayed time against a known-accurate source such as time.is or a GPS clock. On macOS, check System Settings > General > Date & Time. On Windows, open Settings > Time & Language > Date & Time. Even a difference of a few seconds can compound over time if NTP is not functioning.

  3. Check NTP service status

    If your system uses systemd-timesyncd, run timedatectl show-timesync --all to see the NTP server being used and its synchronization status. For systems using chrony, run chronyc tracking to display synchronization details including the current offset and stratum. For ntpd, use ntpq -p to list configured NTP servers and their synchronization status. Verify that at least one NTP server shows an active, synchronized connection.

  4. Force an immediate time synchronization

    If the NTP daemon is running but time is still off, force an immediate sync. If the clock is far off, stop Bitcoin Core first (bitcoin-cli stop), because a large time jump can disrupt running applications; you start it again in step 7. For systemd-timesyncd: sudo systemctl restart systemd-timesyncd. For chrony: sudo chronyc makestep, which jumps the clock by the correction chrony is still slewing. For ntpd or NTPsec: stop the service, run sudo ntpd -gq, which sets the clock once from your configured servers and exits, then restart the service. After forcing the sync, recheck timedatectl status to confirm the system clock updated.

  5. Configure reliable NTP servers

    Edit your NTP configuration to use multiple reliable time sources. For systemd-timesyncd, edit /etc/systemd/timesyncd.conf and set NTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org. For chrony, edit /etc/chrony/chrony.conf and add multiple server lines with the iburst option. With at least three servers, chrony or ntpd can spot a server that gives incorrect time and ignore it. systemd-timesyncd can’t: it asks one server at a time and moves on only if that server stops answering, so extra servers give it a backup, not a check.

  6. Handle virtual machine time drift

    Virtual machines are particularly prone to time drift because they share CPU time with the host and other guests. If running a Bitcoin node in a VM, install and enable the VM guest agent (open-vm-tools for VMware, qemu-guest-agent for KVM/QEMU). Configure chrony with the makestep 1 3 option to allow large time corrections during the first three updates after boot. If the VM can be suspended and resumed with a stale clock, use makestep 1 -1 instead, which lets chrony step the clock on any update (chrony FAQ). On cloud VPS providers, verify that the provider’s NTP service is functioning and accessible from within the VM.

  7. Verify the fix through Bitcoin Core

    After correcting system time, restart Bitcoin Core with bitcoin-cli stop followed by bitcoind -daemon (if you stopped it in step 4, only the second command is needed). Wait until bitcoin-cli getnetworkinfo shows at least five outbound connections in connections_out (usually within a minute), then verify that its timeoffset is near zero. Until the node has heard from five outbound peers since starting, Bitcoin Core reports timeoffset as exactly 0, so an early 0 proves nothing. Check bitcoin-cli getblockchaininfo to confirm that block validation has resumed if it had previously stalled. Monitor ~/.bitcoin/debug.log for any remaining time-related warnings.

  8. Set up ongoing time monitoring

    Add a cron job or systemd timer that periodically checks NTP synchronization status and alerts you if time drift exceeds acceptable thresholds. A simple script can run chronyc tracking | grep "System time" and send an alert if the offset exceeds 0.5 seconds. For nodes with monitoring stacks, Prometheus’s node_exporter enables its timex collector by default; it exports node_timex_sync_status and node_timex_offset_seconds, so Alertmanager can alert you when drift occurs. (Its older ntp collector is deprecated.)

Common Mistakes to Avoid

Assuming the Displayed System Time Is Accurate

The time displayed on your operating system’s clock can appear correct while the underlying system clock is off by several seconds or even minutes. This discrepancy occurs because the display rounds to the nearest minute, or because the timezone is set correctly but the UTC base time is wrong. Always verify time accuracy using NTP tools (chronyc tracking, ntpq -p) rather than trusting the visual clock display. A clock that is a few minutes off is easy to miss on a clock face. Bitcoin Core only rejects new blocks once your clock is more than two hours behind, but since version 28 it warns you at 10 minutes: treat that warning as the cue to fix NTP.

Running a Node Without Any NTP Service

Some minimal Linux installations and container-based deployments do not include an NTP daemon by default. Without active time synchronization, the system clock is usually set from the hardware real-time clock (RTC) at boot and then kept by the kernel on its own, and both clocks can drift by several seconds a day depending on temperature and hardware quality. Over a few months that adds up to minutes, enough to trigger Bitcoin Core’s 10-minute warning, and the error keeps growing until something corrects it. Always verify that an NTP service (systemd-timesyncd, chrony, or ntpd) is installed, enabled, and actively synchronizing.

Using a Single NTP Server

Configuring only one NTP server creates a single point of failure and eliminates the NTP algorithm’s ability to detect and reject incorrect time from a compromised or malfunctioning server. If your sole NTP server provides bad time, your system will follow it blindly. Configure at least three NTP servers, preferably from different operators (e.g., pool.ntp.org servers for your own country or region, plus your ISP’s NTP server). Nearby servers give a more accurate clock than distant ones, whose longer and less even network paths add error. chrony’s FAQ advises at least three servers so it can detect one that gives false time.

Top: one NTP server whose time is 47 minutes off. Your NTP service has nothing to compare it with, so your clock follows it and ends up 47 minutes off too. Bottom: three NTP servers, two right and one 47 minutes off, feeding chrony or ntpd. The service compares them, drops the odd one out and keeps your clock right. A note: systemd-timesyncd asks one server at a time and moves on only if it stops answering, so extra servers give it a backup, not a check; for the check, use chrony or ntpd.
Three servers let your NTP service catch one that is wrong. chrony and ntpd compare their servers and drop the one that disagrees. With a single server, or with systemd-timesyncd, which uses one server at a time, your clock follows whatever it is told.

Ignoring Time Issues in Docker or Container Environments

Docker containers share the host kernel’s clock, so running NTP inside a container has no effect. If the host system’s time drifts, every container on that host is affected. Some operators troubleshoot time inside the container without realizing the fix must be applied at the host level. Verify NTP synchronization on the Docker host, not within the container. For Kubernetes deployments, ensure the underlying node (host) operating system maintains proper NTP synchronization.

Making Large Time Jumps While Bitcoin Core Is Running

Manually setting the system clock forward or backward by a large amount while bitcoind is running can cause unexpected behavior, including rejected blocks and peer disconnections. If a large time correction is needed, stop Bitcoin Core first, correct the system time, then restart the node. Small adjustments (under a second) from NTP’s slewing mechanism are safe during normal operation because they adjust the clock rate gradually rather than jumping.

Frequently Asked Questions

How much time drift does Bitcoin Core tolerate?

Since version 27, Bitcoin Core checks block timestamps against your computer’s own clock, without adjusting it from peers: it rejects blocks more than two hours ahead of that clock, and since version 28 it warns you when your clock is more than 10 minutes out of step with your peers. A clock running more than two hours behind therefore makes the node reject new blocks. For practical purposes, keep your system clock accurate to within a few seconds with NTP.

A ruler of clock error, with your clock ahead to the left and behind to the right. In the middle, a few seconds either way is normal and NTP keeps it there. More than 10 minutes either way: Bitcoin Core 28 and later warns you. More than 2 hours behind: new blocks are rejected. Read the offset in getnetworkinfo's timeoffset field: positive means your clock is behind, negative means it is ahead. The ruler is not to scale.
Only a clock running behind makes your node reject blocks. A few seconds of error is normal. Past 10 minutes either way, Bitcoin Core 28 and later warns you; past 2 hours behind, it rejects new blocks.

What is network-adjusted time and how does it work?

It is how older versions of Bitcoin Core judged block timestamps: the local clock shifted by the median of the time offsets reported by peers, applied only when that median was 70 minutes or less. Bitcoin Core 27.0 removed it from consensus code and uses the unadjusted system clock instead, which removes the old reliance on an honest majority of outbound peers. The node still records the offsets of its outbound peers, but only to warn you: getnetworkinfo reports their median as timeoffset, and since version 28 a median above 10 minutes triggers a warning.

Two panels. Before Bitcoin Core 27.0: your clock plus the median time offset of your outbound peers, used only if it was 70 minutes or less, made network-adjusted time, and that is what each new block was checked against. Since 27.0 (April 2024): your clock alone checks each new block; your peers' offsets only feed the timeoffset field and, since 28.0, a warning when they differ by more than 10 minutes. Your peers can no longer shift the time your node checks blocks against, so keeping your clock right is your job.
Since Bitcoin Core 27.0, your own clock is the only one that counts. Older versions shifted it by your peers’ median offset. Now peers can only tell you, through timeoffset and a warning, that your clock looks wrong.

Can incorrect system time cause my node to fork onto a different chain?

In practice, no. Bitcoin’s consensus rules require that a block’s timestamp is greater than the median of the previous 11 blocks, which prevents backdating. The two-hour future block tolerance prevents excessive forward-dating. Your node would have to be off by more than two hours to reject valid blocks, and even then it would simply stop accepting new blocks rather than follow an alternative chain. The node would effectively stall rather than fork. Correcting the time and restarting resolves the issue.

Does running Bitcoin Core over Tor affect time synchronization?

Tor itself does not affect your system’s NTP synchronization since NTP operates at the OS level, independent of Bitcoin Core’s network connections. However, if your entire system sends all traffic through Tor (a Tor-only setup), ordinary NTP cannot work at all: NTP runs over UDP, and Tor does not carry UDP. Such a system needs another way to set the clock through Tor: Whonix, for example, uses sdwdate and Tails uses htpdate, which both read the time from web servers. That is less precise than NTP, but more than enough for Bitcoin Core.

How can I tell if a block validation failure is caused by a time issue?

Since version 28, Bitcoin Core logs a warning that your computer’s date and time “appear to be more than 10 minutes out of sync with the network” (Bitcoin Core 32.1 source). Blocks and headers dated more than two hours ahead of your clock are rejected as time-too-new (“block timestamp too far in the future”), which only reaches debug.log with validation logging on: start the node with -debug=validation or run bitcoin-cli logging '["validation"]'. Because headers are checked against the same rule, a clock that is far behind makes both headers and blocks in getblockchaininfo stop short of the current height.

Background: why a node needs an accurate clock

A node uses its clock to judge block timestamps, so a wrong clock can stop a Bitcoin node from accepting new blocks.

The Bitcoin network’s reliance on accurate timekeeping stems from its fundamental need to maintain a consistent ordering of transactions across a distributed network. Each block in the blockchain contains a timestamp, and nodes must validate these timestamps as part of their consensus rules. This validation process requires nodes to maintain reasonably accurate system clocks, typically within two hours of network time, to properly participate in the network.

Time synchronization challenges can manifest in various ways during node operation, particularly during the initial blockchain synchronization process. When a node’s system clock differs significantly from the network time, it may encounter difficulties in properly validating blocks and maintaining network consensus. This can lead to synchronization appearing to stall at near-completion, despite the node having downloaded all necessary blockchain data. A clock that runs too far ahead causes a different problem: Bitcoin Core treats the node as still in initial block download while its newest block is more than 24 hours old by the local clock. A node that starts with its clock more than a day ahead therefore stays in that mode, and while it is in it, it ignores transactions from peers.

The relationship between operating system time settings and Bitcoin Core’s internal time checks represents a critical interface between the node software and its host system. Bitcoin Core implements its own time-checking mechanisms, but these ultimately depend on the accuracy of the system clock. This dependency creates a potential point of failure when system time settings become misaligned with actual network time, even if the displayed time appears correct to the user.

Modern operating systems typically maintain time synchronization through Network Time Protocol (NTP) servers, but various factors can disrupt this synchronization. Hardware issues, system hibernation, virtual machine configurations, or network connectivity problems can all potentially impact time synchronization. These disruptions can have subtle but significant effects on Bitcoin node operation.

Block timestamps also drive the difficulty adjustment: every 2,016 blocks, each node recalculates the mining target from the time those blocks took, as recorded in their timestamps. Every node reads the same timestamps from the chain and gets the same result, whatever its own clock says. When your node validates a block, its own clock counts in one check only: whether the block is dated too far in the future to accept.

Bitcoin’s design incorporates several mechanisms to handle time-related challenges in a distributed system. Older versions of Bitcoin Core used what was known as “network-adjusted time”: the local clock shifted by the median of the time offsets reported by peers. Bitcoin Core 27.0 removed it from consensus code, so a current node judges block timestamps by your system clock alone, which makes keeping that clock correct the operator’s job.

For node operators, understanding the relationship between system time and Bitcoin Core operation provides practical insights for troubleshooting and maintenance. Regular verification of system time synchronization should be considered a basic part of node operation hygiene, alongside other maintenance tasks like ensuring adequate storage space and maintaining current software versions.

The resolution of time synchronization issues often requires a systematic approach to troubleshooting. This includes verifying system time settings, checking NTP server configurations, and ensuring proper network connectivity. In some cases, simply triggering a manual time resynchronization can resolve apparent blockchain synchronization issues, even when the displayed time appears correct.

Related Resources

Part of our free Bitcoin course: This topic is covered in Setting Up Your Bitcoin Node Step by Step, from the Lightning Network & Bitcoin Nodes course.
Filed under: Bitcoin Nodes & Infrastructure

Continue Reading

← Back to All Articles