A public NTP server list is a curated set of official Network Time Protocol hostnames that a computer, router, or small network can be pointed at to keep its clock synchronized, typically with one row per hostname showing provider, scope, and leap-second handling. The most useful lists separate consumer-grade pool entries from professionally operated single-vendor services, because the two serve different audiences: volunteers behind the NTP Pool Project run the former, while Google, Cloudflare, and NIST each publish their own production-grade endpoints. A list also differs from a DNS lookup: it tells you the canonical hostnames that the providers actually want you to configure, not the raw IP addresses that may shift without notice. For a developer setting up a workstation, a lab device, or a small office router, a focused reference covering four major providers and eleven hostnames is usually enough — and exactly what a tool like the Public NTP Server List is built to deliver.
What an NTP Server List Actually Contains
A practical NTP server list does more than print domain names. It answers the configuration question by pairing each hostname with the metadata you need to decide whether it belongs in your ntpd.conf, chrony.conf, timesyncd.conf, or Windows Time registry entry. The fields that matter most are:
- Provider — the organization running the server (NTP Pool, Google, Cloudflare, NIST, and a handful of others).
- Hostname — the official name to put in your config. Avoid pinning IP addresses.
- Scope — global, regional, or specialty (Google's time.google.com, for example, covers both anycast and individual hostnames).
- Leap-second handling — whether the provider smears the leap second or follows the IERS leap indicator.
- Operational note — a short hint about round-robin behavior, reachability caveats, or recommended client commands.
The advantage of a static, hand-curated list over an automated scanner is consistency. The reference data behind the Public NTP Server List was checked against the official pages of the NTP Pool Project, Google, Cloudflare, and NIST on 2026-07-18, so the entries match what those providers currently publish rather than what was true at some earlier moment.
The Four Main Public NTP Providers Compared
The NTP ecosystem has many time servers, but four providers cover almost every practical need. A side-by-side view helps you pick one coherent source strategy instead of mixing services that behave differently.
| Provider | Sample hostnames | Scope | Leap handling |
|---|---|---|---|
| NTP Pool Project | 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org | Global volunteer pool, rotating | Uses IERS leap indicator without smearing |
| Google Public NTP | time.google.com, time1.google.com, time2.google.com, time3.google.com, time4.google.com | Global anycast plus individual hostnames | Smears the leap second |
| Cloudflare Time Service | time.cloudflare.com | Global anycast on Cloudflare network | Uses IERS leap indicator without smearing |
| NIST Internet Time Service | time.nist.gov | Round-robin across NIST infrastructure | Distributes UTC(NIST) |
The NTP Pool recommends the rotating 0, 1, 2, and 3.pool.ntp.org names rather than pinning a single volunteer server IP, because the pool balances load and tolerates individual failures automatically. Google provides time.google.com as a single anycast name plus four individual hostnames for users who want explicit endpoints. Cloudflare publishes one hostname, time.cloudflare.com, and routes it through its global network. NIST recommends the round-robin time.nist.gov address rather than hard-coding one server IP. Because all four are hostnames, the underlying addresses can change without requiring a configuration edit on your side.
How to Pick an Entry From an NTP Server List
Once you have a list in front of you, the workflow to land on a working configuration is short and predictable. Follow these steps in order.
- Filter by provider or search for a hostname, scope, or leap-handling note. Pick the provider whose leap behavior matches what the rest of your fleet uses, then narrow the rows by scope (global vs. regional) if your deployment is geo-sensitive.
- Review the provider guidance and avoid mixing incompatible leap-smear strategies. If you choose Google, do not also list Cloudflare or NIST servers in the same client — Google's own documentation warns that mixing smeared time with non-smearing sources produces unpredictable results around a leap second.
- Copy the visible ntpd lines, adapt them to your time client, and verify reachability from the target system. The reference output is one server line per visible hostname with iburst appended. Paste it into ntpd.conf, then translate the same hostnames into the syntax used by chrony, systemd-timesyncd, Windows Time, or your appliance's web UI.
Each step is a small gate: filter first, review the leap policy second, adapt third. Skipping any one of them tends to surface as a problem several months later, when a leap second occurs and a heterogeneous set of sources disagrees about what time it is.
Leap-Second Handling and Why It Matters
Leap seconds are announced by the IERS and inserted into UTC at the end of June or December. Different providers respond differently, and the choice has real operational consequences.
Google explicitly smears the leap second across a window of hours so that downstream clocks never see a discontinuous jump. Cloudflare and NTP Pool servers, by contrast, follow the leap indicator and let the kernel apply the one-second step. NIST distributes UTC(NIST). The problem is mixing: if one source smears and another does not, the time client sees conflicting corrections and may oscillate between them, producing the kind of behavior Google warns against in its own FAQ.
The practical implication is straightforward. If your fleet uses time.google.com, keep only Google hostnames in the configuration. If your fleet uses the NTP Pool, Cloudflare, or NIST, pick one of those and stick with it. A coherent source strategy beats a "more sources is better" instinct, especially around a leap second. For the same reason, the Public NTP Server List tags each row with its leap policy so you do not have to read four separate provider pages to make the comparison.
Adapting the List to Your Time Client
The reference output uses ntpd-style server lines with iburst. That format works on FreeBSD, on Linux distributions that ship ntpd or openntpd, and on many network appliances. It is not, however, the syntax used by the time clients that ship with most modern Linux distributions or with Windows.
- chrony: replace server host iburst with pool host iburst for NTP Pool names, or keep server host iburst for single-host entries. Use chronyc sources to confirm reachability.
- systemd-timesyncd: edit /etc/systemd/timesyncd.conf, set NTP= to a space-separated list of hostnames, then run timedatectl show-timesync to verify.
- Windows Time: use w32tm /config /manualpeerlist:"host1 host2 host3" /syncfromflags:manual /reliable:YES /update, then w32tm /resync to trigger a sync. Hostnames are space-separated, not line-separated.
- Network appliances and routers: paste hostnames into the Time/NTP screen of the management UI. Most vendors accept either a list of hostnames or a single string with spaces.
In every case, the rule is the same: configure hostnames, not IPs, and verify from the target system. Browsers cannot perform a real NTP check, so the reachability confirmation has to happen on the device that will actually use the time source.
When a Public NTP Server List Is Not Enough
A public list is a starting point, and for some environments it is the wrong tool entirely. The browser itself cannot send a normal UDP NTP request to port 123, so no online tool — including this one — can prove that a hostname is reachable from your current network. Firewalls, captive portals, DNS policy, and provider maintenance can all block or break a public source. For infrastructure where wrong time could affect authentication, logs, finance, safety, or incident response, follow the operating-system or equipment vendor's supported configuration, prefer multiple monitored sources, and consider an authenticated or local time architecture such as a local GPS-disciplined server or a vendor's authenticated NTP.
For developer workstations, homelab gear, and small networks, however, a focused public NTP server list is exactly enough. Filter the eleven rows by provider, confirm the leap policy, copy the lines that match your client's syntax, and verify from the target system. That is the whole configuration path. If you want a deeper look at the safety side of online NTP lists specifically, the guide Is a Public NTP Server List Safe to Use Online? walks through what a browser-side tool can and cannot do.