What Is NTP? How to Set Up Time Sync on a Linux Server

What is NTP and what does it do?

NTP, the Network Time Protocol, is the standard way for computers to set their clocks from a reliable time source over a network. The current version, NTPv4, is defined in RFC 5905. Your server asks for the time, measures its error, and corrects the clock gradually over UDP port 123.

In this guide we explain what is NTP from the point of view of a site owner, an e-commerce manager and a developer. We are a digital marketing and web team, not a hosting company. For that reason everything here rests on official documentation and standards. Please check your own distribution's manual before you run any command.

First you will see why accurate time matters. Then we connect it to your hosting choice and the rest of your infrastructure.

What breaks when a server clock is wrong?

A wrong clock hides behind many problems that look unrelated. That happens because security, logging and scheduling all trust the same clock. Even a few minutes of error can cause these symptoms:

• Outgoing HTTPS connections check a certificate's start and end dates (notBefore and notAfter) against your clock. A slow clock makes a valid certificate look "not yet valid".
• Time based one time codes (TOTP) depend on time. RFC 6238 uses 30 second steps by default.
• Log files stop matching each other. Comparing records from several servers becomes nearly impossible.
• Scheduled jobs (cron) fire late, early or twice.
• APIs that check timestamps reject your signed requests.

For example, suppose your server fails to reach a payment provider because of an SSL certificate error. Check the server clock before you blame the certificate. Certificate errors that your visitors see are usually a different issue.

Why should a website owner care about server time?

Server time looks like a technical detail, yet it touches business results. Who asks what is NTP? Not only system administrators, but many site owners. E-commerce owners, marketing managers and developers need the same answer.

For instance, imagine a time based discount on your shop. If the server clock runs slow, the campaign starts late and ends late. Order timestamps also drift. As a result, your order reports and your ad reports stop agreeing with each other.

Similarly, you may read server logs next to analytics data. A clock error then scrambles the order of events. It becomes hard to tell whether an error caused a drop in visitors or the other way round. In short, a small technical drift can push marketing decisions in the wrong direction.

Newsletters and scheduled posts carry the same risk. A wrong clock sends them at the wrong hour. Moreover, nobody notices until a customer complains. Regular time checks remove these surprises.

Why does a server clock drift, and how does NTP fix it?

Every computer keeps time by counting the vibrations of a quartz crystal. That crystal runs slightly fast or slow, depending on temperature and manufacturing differences. A tiny error becomes a visible drift within days.

Also, virtual servers add another problem. A virtual machine can pause or move to another physical host. Then the guest clock may jump at once.

NTP does two jobs here. First, it measures the offset between your clock and a remote server. Then it adjusts the speed of your clock in small steps. We call this slewing. For a very large error it can also jump the clock in one move, which we call stepping.

That way applications rarely see a clock that jumps backward. Still, a step may be needed at first boot.

What is NTP stratum and how do time sources form layers?

Stratum is a number that shows how many steps a time source sits away from a precise reference clock. Atomic clocks and GPS receivers are stratum 0. A server wired directly to them is stratum 1. After that, the number grows by one with each hop.

In other words, a lower stratum does not always mean a better source. Also, network delay and the quality of the source matter. For a website, a stratum 2 or 3 source is usually more than enough.

What is NTP, and how do chrony and systemd-timesyncd differ?

NTP is a protocol, and several programs implement it. On Linux servers you will most often meet ntpd, chrony and systemd-timesyncd. However, which one is the default depends on your distribution. So first look at what runs on your system.

Never run two time clients at the same time. If both try to set the clock on their own, you get inconsistent results. Distributions usually switch one off when you install the other. Still, confirm it with timedatectl.

How do you check whether your server clock is in sync?

Read the current state before you change anything. On most modern Linux distributions the timedatectl command is enough. Then it shows the system time, the time zone and the sync state together.

timedatectl status
date -u
systemctl status systemd-timesyncd
systemctl status chrony

First, look at two lines in the output. "System clock synchronized: yes" means a network time service has set the clock. "NTP service: active" means the time service is running. Older versions may label the first line differently.

On the RHEL family the service is called chronyd. On Debian and Ubuntu it is chrony. If one of them does not exist, the command prints a "unit not found" style error. That error does not mean something broke. It only says the service is not installed.

What is pool.ntp.org and which addresses should you use?

pool.ntp.org is a public pool of time servers that volunteers run, all behind one domain name. According to the official usage page, the names 0, 1, 2 and 3 point to a random set of servers that changes every hour.

• Global names: 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org and 3.pool.ntp.org.
• For regional names you add a continent or country code. The official page gives ch.pool.ntp.org for Switzerland as an example.
• IPv6 addresses come only with zone names that start with 2. For example, 2.pool.ntp.org returns both IPv4 and IPv6.
• The official page advises you to use no more than four time servers.

Also, the pool operators do not want tricks like burst or a very short minpoll, because they add load. For systems where life or business depends on exact time, do not take time straight from the internet. Run a local time server instead. Read the official usage page for the details.

What should you check before you change the time settings?

Touching the time service looks simple, but a live server needs care. First copy the existing setting. Then change one thing at a time, so you can go back quickly if something fails.

• Leave a dated copy next to the main configuration file.
• Prefer a drop in file over editing the main file.
• Change one setting at a time, then restart the service.
• Verify the state before you close your session.

Also, plan your maintenance window. Fiddling with the clock during heavy order traffic adds needless risk. Teams who search what is NTP and rush the setup often forget one step: stopping the old service.

Also confirm that the setting survives a reboot. Starting the service is not enough. You must enable it at boot. The enable --now command in the next sections does both in one step.

systemctl is-enabled chrony
timedatectl status

The command prints enabled for an active service. On the RHEL family the service name is chronyd. If you have no recent copy of your site, build a backup strategy first. Then move on to infrastructure settings.

How do you set up NTP with systemd-timesyncd?

systemd-timesyncd is a simple time client that ships with many distributions. Its configuration file is /etc/systemd/timesyncd.conf. According to the official manual, files under /etc/systemd/timesyncd.conf.d/ take priority over the main file. So it is cleaner to write a drop in file than to edit the main one.

sudo mkdir -p /etc/systemd/timesyncd.conf.d
sudo nano /etc/systemd/timesyncd.conf.d/60-ntp.conf

[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
FallbackNTP=3.pool.ntp.org

sudo systemctl restart systemd-timesyncd
timedatectl timesync-status

The NTP line defines the main servers and the FallbackNTP line defines backups. Backups only apply when no other server information exists. After that, run timedatectl set-ntp true to make sure network time sync is on.

In short, a timesyncd setup takes two files and a restart. If you want detailed measurements, switching to chrony makes more sense.

How do you install and configure chrony?

chrony is a popular NTP implementation for virtual servers and for systems with unstable links. The install command depends on your distribution family. Also, the service name and the configuration path differ.

# Debian and Ubuntu
sudo apt install chrony
sudo systemctl enable --now chrony

# RHEL family
sudo dnf install chrony
sudo systemctl enable --now chronyd

The configuration path depends on the distribution. In practice, the chrony manual lists /etc/chrony.conf as the compiled in default. However, the Debian family usually uses /etc/chrony/chrony.conf. Confirm the file location in your own package documentation.

Three lines do the main work:

pool 2.pool.ntp.org iburst
makestep 1.0 3
rtcsync

The pool line finds your sources. According to the manual, iburst sends a short burst of requests at the start so the first update comes sooner. The makestep line allows a step when the offset exceeds 1 second during the first three updates. Finally, rtcsync keeps the hardware clock trimmed while the system clock is in sync.

How do you verify synchronization with chronyc?

First, do not leave a setup without seeing it work. chrony offers two key commands. First, chronyc tracking summarizes the state of the system clock. Second, chronyc sources -v shows each source one by one.

chronyc tracking
chronyc sources -v
chronyc sourcestats

According to the official manual, the fields in the tracking output mean the following:

If the Leap status line says "Not synchronised", the clock has not settled yet. Then wait a few minutes and run the command again.

What do the symbols in chronyc sources mean?

Every line in the sources output starts with two characters. The first shows the type of the source and the second shows its selection state. Reading them tells you whether the problem sits in the network or in the source.

• An asterisk (*) marks the source chrony currently considers best.
• A plus sign (+) marks other sources it uses for synchronization.
• A minus sign (-) marks a usable source it does not use right now.
• An x marks a falseticker, which means the source disagrees with the majority.
• A tilde (~) marks a source with too much variability.
• A question mark (?) marks a source it cannot use for another reason.

However, question marks are normal in the first lines. After a few minutes you should see at least one asterisk and a few plus signs. If the Reach column stays at 0, the last polls got no answer. In that case check the firewall first.

What do you do when the clock is far off, and is stepping safe?

If the clock is far behind or ahead, the normal correction can take days. In chrony the command that speeds this up is documented as chronyc makestep. It cancels the remaining correction and jumps the clock to the right value at once.

sudo chronyc makestep
chronyc tracking

However, jumping a clock backward is not always harmless. Also, some applications assume that time only moves forward. A clock that jumps back brings these risks:

• The same minute can appear twice in your logs.
• Scheduled jobs may fire again.
• Database records that sort by timestamp can end up in the wrong order.

Therefore do not step the clock by hand on a server that runs a live shop or a payment system. Set a maintenance window first, take a backup and share the responsibility with your hosting provider.

How many seconds of drift cause trouble?

There is no single magic threshold, because every system tolerates time differently. Some checks accept minutes and others fail within seconds. So your goal is to keep the drift as small as you can.

Take an example calculation. Say your server clock runs 90 seconds behind. TOTP codes use 30 second steps, so that gap equals three steps. RFC 6238 recommends allowing at most one step for network delay. As a result, two factor codes may fail on this server.

However, certificates behave differently. Their validity periods last days or months, so small drift causes no trouble. The problem appears when the clock slips by hours or days. In log analysis, however, even a few seconds can scramble the order of events.

In short, monitor the sync state to prevent daily problems. If you analyze log files, you can use our log file analyzer.

Is a time zone the same thing as NTP?

No, they do different jobs. NTP keeps the clock correct. A time zone decides which local time you display for the same moment. A server can be perfectly in sync and still sit in the wrong time zone.

timedatectl list-timezones
sudo timedatectl set-timezone Europe/Istanbul
timedatectl status

The official timedatectl manual defines these commands. The list-timezones command prints available zones, one per line. The set-timezone command changes the system zone.

For example, keeping the server clock on UTC is a common practice. Then you avoid daylight saving confusion when you merge logs from several countries. Show local time only in reports and interfaces. That said, if an existing application depends on the local zone, test before you change it.

How does time work on a virtual server and in a Docker container?

Docker containers share the kernel of their host, and so they share its clock. Therefore you do not need a separate NTP client inside every container. Look for the correct time on the host where the container runs. We cover the container model in our Docker guide.

However, virtual servers are less clear. Some providers set the guest clock with their own mechanism. Then your own NTP client may clash with it. So search your provider's documentation for the recommended way to sync time.

• Container: it follows the host clock, so do not install NTP inside it.
• Virtual server: follow your provider's advice and documentation.
• Shared hosting: the provider owns the clock completely.

Also, most managed cloud services offer their own time source. Still, do not guess. Read the official documentation first.

Which firewall port must stay open for NTP?

NTP uses UDP port 123. A server that works as a client must allow outgoing UDP 123 traffic. You do not need to open incoming traffic, because replies come back as part of the session you opened.

If your firewall restricts outgoing traffic, NTP can fail silently. For example, the symptom looks like this: chronyc sources lists your sources, but the Reach column stays at 0. Meanwhile the system clock keeps drifting, so the error grows.

If you suspect name resolution, use the DNS lookup tool to confirm that the pool names resolve. If you need to inspect an address, our IP lookup tool helps.

Do not open incoming UDP 123 to everyone. Attackers have abused open NTP servers for DDoS reflection in the past. If you do not need your own server, stay a client only.

When should you run your own NTP server?

For most websites and online shops the answer is no. A single VPS or a small group of servers gets accurate time from the pool or from the provider's time source. In practice, your own server brings maintenance work and security duties.

Still, a local time server makes sense in a few cases:

• In closed networks without internet access.
• When many servers must use the same source.
• When regulations tie your time source to a specific setup.

chrony can act as a server, but that needs extra configuration. Remember to limit which clients can reach it. See the chrony configuration manual for details. For a critical environment, work with a system administrator.

What do common NTP symptoms point to?

When you troubleshoot, moving from symptom to likely cause saves time. The table below is a starting point that we drew from the facts in this guide. Every system differs, so read the rows as hints and not as a final diagnosis.

From a security view, the time service is also an attack surface. For general web security, read our OWASP Top 10 guide.

Which common mistakes do people make when they ask what is NTP?

The same mistakes repeat in the field. The list below comes from official warnings and the logic of this guide. If you spot one on your own server, fix it first.

• Running two time clients at the same time.
• Listing more than four servers for the pool.
• Adding load with burst or a very short minpoll.
• Closing UDP 123 outbound and never looking for the cause.
• Stepping the clock backward on a live system.
• Installing a separate NTP client in every Docker container.
• Treating the time zone and synchronization as the same thing.

Most of these mistakes come from copying commands without understanding them. So we suggest reading what each command does in the official documentation. For example, the manual describes chronyc makestep as the command that jumps the clock at once.

When should you not do this yourself and leave it to your hosting provider?

You do not have to act on your own every time. In the cases below it is safer to leave the work to your provider. Besides, most providers include this support in the service.

• On shared hosting and cPanel accounts you cannot touch the server clock anyway. The provider manages it.
• On a managed VPS or cloud service, the provider syncs time with its own method.
• On a server that runs live payments, stock or bookings, stepping the clock by hand is risky.
• If you run a database cluster, clock differences can cause replication problems.
• If you are unsure what a command does, try it in a test environment first.

Also, it helps to state clearly what you want. Ask your provider: "Which service syncs the clock, and what is its current state?" A good support team answers quickly.

If you want to think about infrastructure together with your website goals, look at our web design and development service. Our data security guide also helps you protect your data.

What is the final checklist for an NTP setup?

Run the steps below in order before you finish. Each step verifies the one before it, so keep the order.

1. Read the current state with timedatectl status and note it down.
2. Find out which time client runs. Only one should run at a time.
3. Write the pool addresses and add no more than four servers.
4. Restart the service and wait a few minutes.
5. Verify the sync state in the timedatectl and chronyc tracking output.
6. Check that the firewall allows UDP 123 outbound.
7. Choose the time zone on purpose, and use UTC if you can.
8. Check certificates, two factor codes and log files once.

In conclusion, the practical answer to what is NTP is this: once you set it up correctly, you hardly notice it. When it breaks, however, it silently breaks many things. A habit of regular checks is worth more than the setup itself. If you do not manage your own server, hand this list to your provider as a list of questions.