How to Check and Fix NTP Time Sync (Windows, Linux, macOS)

July 07, 2026 — LiveStream

Ever had those head-scratching moments where logins fail inexplicably, certificates scream "not yet valid," or logs from different servers tell completely different stories? Chances are, you've met the silent saboteur: clock skew. Accurate Network Time Protocol (NTP) synchronization is non-negotiable for system stability, preventing critical failures in authentication, security, and distributed services. This guide will walk you through verifying and fixing your NTP time sync across Windows, Linux, and macOS, ensuring your systems always march to the same, precise beat.

Why Accurate Time Synchronization is Absolutely Critical (It's Not Just About Looking Good)

Dekho yaar, accurate time feels like such a trivial thing, right? Until it breaks. Then suddenly, your entire infrastructure starts acting like a confused mess. It's like having a symphony orchestra where every musician thinks they're playing a different piece. Chaos! Mostly, this chaos boils down to something called clock skew – the difference in time between machines. And trust me, for a DevOps engineer, understanding and maintaining precise time sync through NTP (Network Time Protocol) is as fundamental as having a stable network connection.

Let’s break down why this isn't just some best practice for the sake of it; it's foundational:

• Authentication Breaks Down: This is probably the most common and frustrating symptom. Systems like Kerberos (the backbone of Microsoft Active Directory) are extremely time-sensitive. If your client machine's clock drifts by more than about five minutes from the domain controller's clock, Kerberos will simply reject your authentication requests. "Invalid credentials," it’ll say, while you pull your hair out, thinking it’s a password issue. Similarly, many TLS/SSL protocols have built-in time checks to prevent replay attacks and ensure freshness.
• Certificates Misfire: Imagine a server with a clock running too fast. It might see a perfectly valid TLS certificate as "not yet valid," even if it became active moments ago. Conversely, a slow clock might continue to trust an expired certificate, opening up serious security vulnerabilities. This isn't just for web servers; internal systems, microservices, and VPNs all rely on certificates being valid within their defined time windows.
• Logs Become Useless: In a distributed environment, you're constantly correlating events across multiple servers to diagnose issues. If Server A thinks an event happened at 10:00:05 and Server B thinks its related event happened at 10:00:01, while in reality, they were simultaneous, good luck figuring out the causality! Log correlation becomes a nightmare, making troubleshooting incredibly difficult, if not impossible.
• Distributed Systems Fail Hard: Modern applications often run across multiple nodes, databases, and microservices. These systems rely heavily on synchronized time for critical functions:
  • Database Consistency: Many distributed databases use timestamps for transaction ordering and conflict resolution. Inconsistent clocks can lead to data corruption or split-brain scenarios.
  • Cluster Management: High-availability clusters, container orchestrators like Kubernetes, and message queues all depend on a common understanding of time for leader elections, resource scheduling, and event processing.
  • Token-Based Authentication: Think of TOTP (Time-based One-Time Passwords) or 2FA (Two-Factor Authentication). They generate codes based on current time. If your device's clock is off, your generated code won't match what the server expects, and you're locked out.

So, you see, it’s not just an academic exercise. Time synchronization is a fundamental building block for a robust and secure IT infrastructure. Without it, the house of cards quickly collapses.

Understanding the Core of NTP: Where to Get Your Time

Alright, so we know accurate time synchronization is paramount. Now, how do we achieve it? The answer is NTP. It’s a network protocol designed specifically for this purpose. But where do your machines get this "accurate time" from?

The NTP Hierarchy: Stratum Explained

NTP works on a hierarchical system called stratums. Imagine a chain of command for time:

• Stratum 0: These are highly accurate atomic clocks (like cesium clocks or hydrogen masers) or GPS receivers. They are the ultimate source of truth.
• Stratum 1: Servers directly connected to Stratum 0 devices. They synchronize their time directly from these ultra-precise sources.
• Stratum 2: Servers that synchronize their time from Stratum 1 servers. Most internet NTP servers fall into this category.
• Strat3 and below: These servers synchronize from Stratum 2 servers, and so on.

The lower the stratum number, the closer the time source is to a highly accurate reference clock. Generally, you want your systems synchronizing with a server that has a reasonably low stratum (e.g., Stratum 2 or 3) to ensure precision.

Best Practices for Sourcing Your Time

Choosing the right time source is crucial. Here are the common approaches:

1. Network Advertised via DHCP: In many enterprise networks, your routers or DHCP servers will advertise internal NTP server addresses. This is often the ideal scenario because it keeps time synchronization traffic within your local network, reducing latency and reliance on external internet connections.
2. The NTP Pool Project (pool.ntp.org): For standalone machines or smaller networks without dedicated internal NTP servers, the NTP Pool Project is an excellent, globally distributed, and free option. When you point your machine to pool.ntp.org (or region-specific variants like 0.pool.ntp.org, 1.pool.ntp.org, etc.), it automatically resolves to a cluster of geographically close NTP servers, providing robust and reliable synchronization. It's a fantastic community effort, but remember, these are public servers, so don't expect Stratum 1 precision for critical infrastructure unless you're contributing to the pool.
3. Your Organization's Internal NTP Servers: For enterprise environments, setting up your own dedicated NTP servers (often configured as Stratum 2 servers, syncing from Stratum 1 external sources) is the best practice. This gives you full control, improves security, and ensures consistent time across all your internal systems, regardless of external internet connectivity.
4. Domain Controller Hierarchy (for Active Directory): In a Windows Active Directory domain, member machines should *always* sync their time from their domain controllers. The domain controllers form a hierarchical time synchronization structure, with the PDC Emulator FSMO role holder typically synchronizing from an external, reliable NTP source (like pool.ntp.org or government-provided time servers). This ensures that all machines within the domain have synchronized time, which is vital for Kerberos authentication to function correctly. Never manually override the NTP settings on a domain-joined machine unless explicitly instructed for very specific scenarios!

Got it? Good. Ab chalte hain, let's see how to actually check and fix this on your different operating systems.

Checking and Fixing NTP Time Sync on Linux

Linux systems offer a few different ways to manage time, depending on the distro and how modern it is. Let's look at the popular ones.

Systemd-timesyncd (Most Modern Distros)

If you're running a modern Linux distribution like Ubuntu 16.04+, Debian 9+, Fedora, or CentOS 8+, you're likely using systemd-timesyncd as your default NTP client. It's lightweight and integrates well with systemd.

Checking Status:

The command to rule them all for time-related info on systemd-based systems is timedatectl. From your terminal, run:

timedatectl status

What you're looking for here are two key lines:

• System clock synchronized: yes: This tells you whether the system clock is currently synchronized with an NTP server. If it's no, you have a problem.
• NTP service: active: This indicates that systemd-timesyncd (or whatever NTP client is active) is running and attempting to synchronize time. If it's inactive, the service isn't even trying.

You might also see NTP synchronized: yes which is another good indicator. If RTC in local TZ: no is present, it means your Real-Time Clock (hardware clock) is set to UTC, which is generally the recommended setup.

Enabling and Configuring:

If NTP service: inactive or System clock synchronized: no, you likely need to enable the NTP service:

sudo timedatectl set-ntp true

This command enables and starts systemd-timesyncd. If you were previously using another NTP client (like ntpd or chrony), this command might try to disable them, as you generally want only one NTP client running to avoid conflicts.

To configure which NTP servers systemd-timesyncd uses, you can edit its configuration file, typically /etc/systemd/timesyncd.conf. Look for the [Time] section and uncomment/add your desired NTP servers:

# /etc/systemd/timesyncd.conf
[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=time.google.com

After modifying the config, restart the service:

sudo systemctl restart systemd-timesyncd

Chrony (The Modern Standard for Enterprise Linux)

chrony is increasingly becoming the default NTP client in many enterprise Linux distributions like Red Hat Enterprise Linux (RHEL), CentOS Stream, and Fedora. It's preferred over ntpd for its quicker sync times, better performance on intermittent networks, and superior handling of virtual machine clock drift. If you're running RHEL 7/8/9, CentOS 7/8/Stream, or Fedora, chrony is probably what you're using.

Checking Status and Offset:

To see which NTP sources chrony is using and their status, use:

chronyc sources -v

This command gives you a detailed list of configured NTP servers, their stratum, reach, and current offset. A * next to a source indicates it's the currently selected source. Look at the Offset column; you want values as close to zero as possible (ideally in single-digit milliseconds).

For more detailed tracking information, including the system's current clock offset and frequency drift:

chronyc tracking

Here, you'll see crucial information like Reference ID (the ID of the server it's syncing from), Stratum, System time (your current clock offset from the NTP source), Frequency (how much your system clock is drifting per second), and Last offset. Keep an eye on System time – if it's large, your clock is significantly off.

Configuring Servers:

chrony's configuration file lives at /etc/chrony.conf. Here's a typical setup:

# /etc/chrony.conf
# Use the NTP Pool Project servers
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst

# This directive synchronizes the system clock when it is
# substantially different from the NTP servers, if necessary
makestep 1 3

# Log file location
logdir /var/log/chrony

# Allow NTP client access from local network
# allow 192.168.1.0/24

# For servers that do not have access to an NTP server, but other computers will use it as an NTP server.
# local stratum 10

# Drift file location
driftfile /var/lib/chrony/drift

# RTC synchronization
rtcsync

After editing /etc/chrony.conf, you need to restart the chronyd service to apply the changes:

sudo systemctl restart chronyd

Forcing an Immediate Resync (Stepping the Clock):

If your clock is significantly off (e.g., by several minutes or hours), chrony usually won't "jump" the time to avoid issues with running applications. It prefers to gradually adjust it. However, in certain troubleshooting scenarios or after a major clock drift, you might need to force an immediate step:

sudo chronyc makestep

This command will force chrony to immediately adjust the system clock if the offset is larger than the threshold specified in makestep (often 1 second).

NTPD (Legacy but Still Around)

ntpd is the traditional NTP daemon and was the default for a long time on many Linux distributions. While still functional, it's generally being phased out in favor of chrony due to chrony's modern features and better performance in many scenarios. You might encounter it on older systems or specific legacy setups.

Checking Peers and Offset:

To see which NTP servers ntpd is peering with and their status, use:

ntpq -p

This output is similar to chronyc sources -v. You'll see a list of configured peers. The * character next to a server means it's the currently selected synchronization source. The offset column shows the difference between your clock and the server's clock in milliseconds. You want this value to be small.

• reach: This is an octal value that indicates the success of the last 8 polls. A value of 377 means all 8 polls were successful, which is what you want to see.
• stratum: The stratum of the peer.
• delay: The round-trip delay to the server.
• jitter: The variation in network latency.

Configuring Servers:

The configuration file for ntpd is typically located at /etc/ntp.conf. Here’s a basic example:

# /etc/ntp.conf
# Use the NTP Pool Project
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst

# Drift file location
driftfile /var/lib/ntp/ntp.drift

# Logging configuration
# logfile /var/log/ntp.log

# Allow queries from localhost
restrict 127.0.0.1
restrict -6 ::1

# For clients to sync from this server (if configured as an NTP server)
# restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Enable kernel time synchronization
includefile /etc/ntp/crypto/pw

# RTC synchronization
# ntpd will update the real-time clock every hour in order to survive restarts
# without a loss of accuracy.
# saveconfigfile /etc/ntp/temp/ntp.cfg
# rtcfile /etc/ntp/rtc

# Set up NTP statistics recording
# statsdir /var/log/ntpstats/
# filegen peerstats file peerstats type day enable
# filegen loopstats file loopstats type day enable
# filegen clockstats file clockstats type day enable

After editing /etc/ntp.conf, restart the ntpd service:

sudo systemctl restart ntpd

Remember, only run *one* NTP client service at a time (systemd-timesyncd, chronyd, or ntpd) to prevent conflicts and unexpected behavior. Always stop and disable other services if you're switching.

Managing Time Synchronization on Windows

Windows systems use the Windows Time service (W32Time) for NTP synchronization. It’s built-in and generally works quite reliably, especially within an Active Directory domain. Agar tum Active Directory environment mein ho, then most of the time you won't need to manually configure anything on client machines.

Checking Status and Source:

You’ll need an elevated Command Prompt or PowerShell (Run as Administrator) for these commands.

To query the current status of the Windows Time service, including its last successful sync and the time source:

w32tm /query /status

Look for:

• Source: This tells you which NTP server your machine is currently syncing from. In a domain, it should be a domain controller. For standalone machines, it might be time.windows.com or whatever you've configured.
• Last Sync Time: When the last successful synchronization occurred.
• Stratum: The stratum of the current time source.

To specifically query just the configured time source:

w32tm /query /source

Forcing a Resync:

If you suspect your clock is off and want to force an immediate synchronization, use:

w32tm /resync

This command tells the W32Time service to immediately try to synchronize its time. You might get an error if the service isn't running or if there's no configured source. If you get an error like "The computer did not resync because no time data was available," it likely means the service couldn't reach its configured NTP server.

Setting a Manual Source (for Standalone PCs):

For standalone Windows PCs not joined to a domain, or for domain controllers (specifically the PDC Emulator) that need an external source, you can manually configure the NTP server:

w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /update
net stop w32time && net start w32time

Let's break this down:

• /config: Enters configuration mode for W32Time.
• /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org": Specifies the list of NTP servers to use. You can list multiple servers separated by spaces.
• /syncfromflags:manual: Tells the service to synchronize from the manually specified peers.
• /update: Applies the changes to the service.
• net stop w32time && net start w32time: Restarts the Windows Time service to ensure the new configuration takes effect immediately.

Important: As mentioned before, if your PC is joined to an Active Directory domain, it will automatically sync from the domain hierarchy. Do not use /config /manualpeerlist on a domain-joined PC unless you absolutely know what you're doing and have a very specific reason, as it can disrupt domain authentication.

For domain controllers, especially the PDC emulator, you'll configure an external source similarly, but often through Group Policy or dedicated commands aimed at the domain's time synchronization policy. For more in-depth AD time sync management, check out our guide on Active Directory best practices.

Ensuring Time Accuracy on macOS

macOS also provides straightforward ways to manage time synchronization, typically handled by ntpd in the background, but configurable through system settings or the command line.

Checking Current Time Synchronization:

The simplest way for a user to check is through the GUI:

• Go to System Settings (or System Preferences on older macOS versions).
• Navigate to General.
• Click on Date & Time.

Here, ensure that "Set time automatically" is enabled. This setting uses Apple's default NTP servers (like time.apple.com) or those provided by your network via DHCP.

From the command line, you can try to query an NTP server directly using sntp, which is usually included:

sntp -sS time.apple.com

This command will query time.apple.com and print the synchronized time. If it succeeds, it indicates basic network connectivity to an NTP server. However, it doesn't directly show the status of the background NTP daemon.

Setting the NTP Server:

If you need to change the NTP server for macOS (e.g., to use your internal company NTP server or a specific pool server), you can do so via the command line with sudo systemsetup:

sudo systemsetup -setnetworktimeserver 0.pool.ntp.org
sudo systemsetup -setusingnetworktime on

The first command sets the specified NTP server, and the second ensures that automatic network time synchronization is enabled. After running these, you might want to restart the system or wait for the next sync interval. You can verify the configured server with:

sudo systemsetup -getnetworktimeserver

Forcing an immediate resync isn't as straightforward as on Windows or Linux with a dedicated command, but setting the server and ensuring automatic time is on should trigger a sync relatively quickly. You can also try toggling the "Set time automatically" setting off and then on again in System Settings.

Demystifying NTP Output: What the Numbers Mean

When you run commands like chronyc tracking, ntpq -p, or even w32tm /query /status, you get a bunch of numbers. Don't just stare at them blankly; understanding these values helps you quickly diagnose synchronization health.

• offset (or System time offset): This is perhaps the most crucial value. It tells you how far off your system's clock is from the NTP server's clock, usually in milliseconds (ms).
  • What to look for: Ideally, you want this value to be as close to 0 as possible, typically less than a few milliseconds (e.g., < 5-10ms). Anything consistently over 50-100ms indicates a significant clock skew that needs attention. Large positive or negative values mean your clock is fast or slow, respectively.
  • Where to find it:
    • ntpq -p (offset column)
    • chronyc tracking (System time)
    • w32tm /query /status (Time Offset, though it's less direct)
• stratum: We talked about this! It indicates the distance from a reference clock.
  • What to look for: A lower stratum number (e.g., 1, 2, 3) means your time source is closer to a highly accurate atomic clock. Your system should typically synchronize with Stratum 2 or 3 servers. If your system is showing a very high stratum (e.g., 16), it often means it's not synchronized with any external source or has fallen back to its local clock.
  • Where to find it:
    • ntpq -p (st column)
    • chronyc tracking (Stratum)
    • w32tm /query /status (Stratum)
• reach: This value (often displayed in octal, like 377) shows the success rate of recent polls to the NTP server. It's a bitfield that tracks the last 8 polls.
  • What to look for: A value of 377 (decimal 255) means the last 8 attempts to reach the NTP server were successful. If this number is lower (e.g., 177, 000), it indicates intermittent connectivity issues or that the NTP server is unreachable.
  • Where to find it:
    • ntpq -p (reach column)
    • chronyc sources -v (Reach column)
• synchronized / NTP service: active (on Linux timedatectl): A simple, high-level indicator.
  • What to look for: You want to see yes for System clock synchronized and active for NTP service. This confirms that an NTP client is running and successfully adjusting your system's clock.
  • Where to find it: timedatectl status

Regularly checking these values will give you a quick health check of your NTP time sync and help you pinpoint issues before they cause widespread problems.

Common Pitfalls and Troubleshooting NTP Issues

Even with everything configured correctly, NTP can sometimes be a bit finicky. Here are some common issues and how to tackle them:

1. UDP Port 123 Blocked: NTP primarily uses UDP port 123. If your server or a client machine can't reach the NTP server, the first thing to check is your firewall.
   • Troubleshooting: Ensure UDP/123 is open outbound from your client to the NTP server, and inbound if you're setting up an internal NTP server. Use nmap -sU -p 123 <NTP_SERVER_IP> on Linux or a port scanner on Windows to check connectivity. Make sure security groups in cloud environments (AWS, Azure, GCP) also allow this traffic.
2. Two Time Services Fighting: Running multiple NTP clients (e.g., ntpd and chrony simultaneously on Linux, or W32Time plus a third-party NTP client on Windows) is a recipe for disaster. They will conflict, causing erratic time jumps and unstable synchronization.
   • Troubleshooting: Always ensure only one NTP service is enabled and running. On Linux, use systemctl status <service_name> for ntpd, chronyd, and systemd-timesyncd, then disable and stop the ones you don't intend to use. On Windows, verify no other third-party time sync software is installed.
3. VM Clock Drift: Virtual machines are notorious for clock drift. Because they don't have direct access to hardware clocks, their virtual clocks can drift significantly from real time, especially under heavy load or during host migrations.
   • Troubleshooting: Always run an NTP client (like chrony or systemd-timesyncd) *inside the guest OS*. Don't solely rely on the hypervisor's time synchronization features (e.g., VMware Tools' time sync) as they can sometimes interfere or not be precise enough. Configure your guest VM to sync from reliable NTP sources just like a physical machine. We have a detailed article on mitigating VM clock drift.
4. Huge Initial Offset Not Corrected: If a system's clock is drastically off (e.g., by several hours or days), some NTP daemons might refuse to "step" the time, meaning they won't make a sudden jump to correct it. They prefer to "slew" (gradually adjust) the time to avoid potential application issues.
   • Troubleshooting: In such cases, you need to perform an initial forced synchronization.
     • Linux (Chrony): sudo chronyc makestep
     • Linux (ntpd - with caution): You might need to stop ntpd, manually set the time with ntpdate (now deprecated, use chronyd -q 'pool 0.pool.ntp.org'), then restart ntpd.
     • Windows: w32tm /resync /force
     Always be cautious when stepping time on a production system, as it can confuse running applications.
5. Wrong Timezone vs. Wrong Time: Sometimes, the time displayed is incorrect, but the underlying clock sync is fine. This can happen if the system's timezone is configured incorrectly.
   • Troubleshooting: On Linux, use timedatectl status to check both RTC in local TZ and Time zone. Ensure your timezone is set correctly (e.g., timedatectl set-timezone Asia/Kolkata). On Windows, check the Date & Time settings in the Control Panel. A timezone issue isn't an NTP problem; it's a display problem.
6. Network Latency and Jitter: High network latency or jitter between your client and the NTP server can reduce the accuracy of synchronization, even if the server is reachable.
   • Troubleshooting: Check the delay and jitter values in ntpq -p or chronyc sources -v. If they are consistently high, consider using NTP servers that are geographically closer or on your local network.

By keeping an eye out for these common issues and knowing the right commands, you'll be able to keep your systems perfectly synchronized, avoiding a whole host of "impossible" bugs.

Key Takeaways

• Time Sync is Non-Negotiable: Clock skew causes critical failures in authentication (Kerberos/AD, TLS), certificate validation, log correlation, and distributed system stability.
• Quick Status Checks Are Your Friends: Use timedatectl status (Linux/systemd), chronyc tracking / ntpq -p (Linux), or w32tm /query /status (Windows) to quickly assess your time sync health.
• Choose Reliable Time Sources: Prioritize DHCP-advertised servers, your internal NTP servers, or the robust NTP Pool Project (pool.ntp.org). Domain-joined Windows PCs *must* sync from their domain controllers.
• Understand the Output: Pay attention to offset (aim for < few ms), stratum (lower is better, typically 2-3), and reach (377 is ideal) to interpret NTP health.
• Watch for Common Pitfalls: Be aware of blocked UDP/123, conflicting NTP services, virtual machine clock drift, large initial clock offsets, and correctly distinguish between time vs. timezone issues.

Frequently Asked Questions

What port does NTP use?

NTP exclusively uses UDP port 123. If you're experiencing mysterious time synchronization failures, always check your firewall rules (both on the client and network devices) to ensure outbound UDP/123 traffic is permitted to your configured NTP servers.

Should I use chrony or ntpd on Linux?

For modern Linux systems, chrony is generally the recommended and preferred choice. It offers faster synchronization, better handling of intermittent network connections, and superior performance in virtualized environments due to its more efficient clock discipline algorithm. Use ntpd primarily on legacy systems that already depend on it or if you have specific requirements that chrony doesn't meet.

How do I force an immediate time resync?

To force an immediate, one-time synchronization, you can use:

• Linux (Chrony): sudo chronyc makestep
• Windows: w32tm /resync /force (from an elevated command prompt)
• macOS: While there isn't a direct "force resync" command for the daemon, toggling "Set time automatically" in System Settings or running sudo sntp -sS time.apple.com can trigger an update.

Use forced resyncs cautiously on production systems with significant clock differences, as sudden time jumps can sometimes affect running applications.

Why do my Kerberos/Active Directory logins keep failing?

Persistent Kerberos or Active Directory login failures, especially with generic "invalid credentials" errors, are a classic symptom of clock skew. Kerberos is highly sensitive to time differences and will reject authentication requests if the client's clock drifts by more than approximately five minutes from the domain controller's clock. Synchronizing the client's time using NTP (or ensuring it's correctly syncing with a domain controller) is often the quick fix for these issues.

And there you have it, folks! The complete lowdown on NTP time sync. Make it part of your standard build process, and you'll prevent a whole class of infuriating, "impossible" authentication and certificate bugs from ever seeing the light of day. If you want to see these commands in action and get more practical insights, do check out the original video on this topic. Happy syncing!

For a visual walkthrough and more hands-on demonstration of these steps, be sure to watch the full video on the @explorenystream YouTube channel. Don't forget to like and subscribe for more essential DevOps tips!