A simple UDP port check proves very little. An NTP server can answer requests while using the wrong upstream source, operating at an unexpected stratum or returning time that differs significantly from the rest of the environment.

A useful monitoring design combines local checks, external NTP queries and event-log monitoring.

What should be monitored?

For Windows Time Service, useful checks include:

  • The Windows Time service is running.
  • The expected source is selected.
  • The last successful synchronisation is recent.
  • The current stratum is sensible.
  • The measured offset remains within an acceptable range.
  • The source has not changed unexpectedly.
  • The event logs do not contain repeated warnings.

For a Chrony or GPS-backed server, also monitor:

  • The Chrony service is running.
  • GPSD is running.
  • The GPS receiver is producing valid data.
  • PPS remains available where used.
  • The server is operating at the expected stratum.
  • Clients are contacting the service.

Local Windows checks

The basic local checks are:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

These show the selected source, last successful synchronisation and effective configuration.

A scheduled script can collect this output and alert when:

  • The source becomes Local CMOS Clock.
  • The source becomes Free-running System Clock.
  • The source changes to a hypervisor provider unexpectedly.
  • The last successful sync exceeds an agreed age.
  • The reported leap status indicates an unsynchronised source.

External Windows testing

Use another Windows computer to compare its clock with the monitored source:

w32tm /stripchart /computer:time.example.com /samples:5 /dataonly

This confirms that the server answers NTP requests and shows the measured offset from the monitoring computer.

It does not prove that the monitored server is using the correct upstream source. Combine it with local source and status checks.

Monitoring Active Directory time

In a normal Active Directory forest:

  • The forest root PDC Emulator should use the approved upstream source.
  • Other domain controllers should use the domain hierarchy.
  • Domain members should use a domain controller.

Compare domain controllers with:

w32tm /monitor

Look for one domain controller whose offset is significantly different from the others or which cannot be contacted.

The most important alerts are:

  • The forest root PDC Emulator changes source unexpectedly.
  • The PDC Emulator falls back to the local clock.
  • A domain controller stops advertising time.
  • Offsets between domain controllers increase beyond the normal baseline.

Windows Time event logs

Monitor the System log for repeated events from:

Microsoft-Windows-Time-Service

Also review:

Applications and Services Logs
  Microsoft
    Windows
      Time-Service
        Operational

A single warning during startup is not necessarily a fault. Alert on repeated failures without a later success event.

See Windows Time Event Logs for the event IDs most often encountered.

Monitoring Chrony locally

The most useful Chrony commands are:

chronyc tracking
chronyc sources -v
chronyc sourcestats -v
chronyc clients

They provide:

  • The selected reference source.
  • The current stratum.
  • The system-time offset.
  • The estimated error.
  • The state of alternative sources.
  • The clients using the server.

Monitoring GPS and PPS

For a GPS-backed server, Chrony monitoring alone does not prove that the receiver still has a valid fix.

Check GPSD with:

cgps -s

Check PPS with:

sudo ppstest /dev/pps0

Useful alerts include:

  • GPSD stopped.
  • No valid GPS fix for an agreed period.
  • PPS device missing.
  • Chrony no longer selecting the GPS or PPS source.
  • The server falls back to an Internet source.

Using TICC-DASH

TICC-DASH provides a browser view of clients contacting a Chrony server.

It is useful for checking:

  • Which clients are using the server.
  • When each client was last seen.
  • Whether requests are being dropped.
  • Whether an expected subnet is missing.

Using Uptime Kuma

Uptime Kuma 2.5 and later includes a native NTP monitor.

The monitor sends an actual NTP query and can evaluate:

  • Availability.
  • Stratum.
  • Time offset.
  • Round-trip delay.
  • Root dispersion.
  • Reference ID.

Configurable thresholds can mark the monitor down when:

  • The server reports Stratum 16.
  • The stratum meets or exceeds the configured limit.
  • The absolute offset exceeds the configured limit.
  • Root dispersion exceeds the configured limit.

This is much more useful than a simple UDP port check because it validates the returned NTP data.

Choosing alert thresholds

Thresholds should reflect the purpose of the monitored source.

For an ordinary internal NTP server, a practical starting point may be:

  • Alert if the service is unreachable.
  • Alert if the server reports Stratum 16.
  • Alert if the stratum changes unexpectedly.
  • Alert if the offset exceeds the normal baseline by a meaningful amount.
  • Alert if root dispersion increases sharply.

A GPS-backed Stratum 1 server should normally remain Stratum 1 while GPS is selected. A change to Stratum 2 may indicate that it has fallen back to an Internet source rather than a total failure.

Avoid using unrealistically tight offset thresholds on an Internet-based monitor. Network delay and asymmetry affect the measured result.

Monitor source changes

Availability can remain green while the quality of the time path changes.

Examples include:

  • The forest root PDC Emulator falls back to its local clock.
  • A virtual machine starts using host time.
  • A GPS-backed Chrony server falls back to an Internet source.
  • A DNS service name is redirected to another server.

Source changes should therefore be logged and, where important, alerted separately from service availability.

Monitor from another system

Local monitoring confirms what the server believes. External monitoring confirms what clients can reach.

Where possible, run the independent NTP check from another physical or virtual host. Monitoring a Chrony server from the same machine proves very little about routing, firewall rules or network availability.

What monitoring cannot prove

Even a comprehensive monitoring setup has limits.

It may not immediately detect:

  • A trustworthy-looking source providing consistently wrong time.
  • A virtualisation host correcting a guest only during startup or migration.
  • A receiver with poor antenna placement that remains barely usable.
  • A manual clock change that is corrected before the next check.
  • A DNS answer that differs between client networks.

Occasional manual verification remains useful, particularly after changes to Active Directory, hypervisors, firewalls, DNS or the GPS receiver.

A practical monitoring design

For most small environments, a sensible design is:

  1. Monitor the Windows Time or Chrony service locally.
  2. Record the selected source and last successful synchronisation.
  3. Query the NTP service externally with Uptime Kuma or another NTP-aware monitor.
  4. Monitor Windows Time event logs.
  5. Use w32tm /monitor for Active Directory domain controllers.
  6. Use TICC-DASH where client visibility is useful.
  7. Check GPS and PPS separately on a Stratum 1 server.

This provides enough evidence to distinguish a service outage, a source failure, a clock-quality problem and a client-access problem without building an unnecessarily complex monitoring platform.

Further information

Related information