Clock health affects more than a displayed timestamp
Authentication, certificate checks and incident timelines all depend on sensible time. A time daemon's process can be running while the host has no usable synchronization source. The first diagnostic goal is to establish where the clock estimate comes from, how recent that evidence is and whether the application is affected.
This guide uses chrony terminology. It is not a procedure for replacing a domain time hierarchy or overriding a cloud provider's supported time arrangement. In mixed environments, document which system owns synchronization for each host and avoid competing daemons or conflicting host-guest policies.
Setup: read tracking and source evidence
Record the chrony version, virtualization context and configured sources. chronyc tracking reports the selected reference and clock-performance information; chronyc sources -v helps inspect source state. Interpret the fields using the installed manual, including leap status, reference time, reachability and offset rather than one isolated number.
Inspect the effective chrony configuration and whether source names resolve and can be reached through the authorized network path. Network Time Security, when configured, introduces its own trust and connectivity requirements. A healthy DNS query alone does not prove that time exchanges or authenticated source establishment succeed.
Illustrative incident: the service survives an egress change
An illustrative firewall change leaves the time daemon running but prevents it from obtaining useful updates. Later, an application reports time-related authentication failures. This is a constructed operational example and does not describe a named or anonymous client.
Correlate the last accepted source measurement with the network change and the application's failure interval. Check the host's reference against an independent approved source. If the clock itself is unreliable, label uncertainty in incident timestamps rather than forcing log lines into an apparently precise sequence.
Troubleshooting: separate source and correction problems
| Observation | Evidence | Question to answer |
|---|---|---|
| No usable selected source | Source states, reachability and logs | Are sources reachable and considered trustworthy? |
| Reference measurement is old | Tracking reference time and network events | When did useful updates stop? |
| Source is selected but offset remains concerning | Offset trend and correction policy | Is adjustment converging as intended? |
| Only one virtual guest is affected | Guest configuration and host policy | Are multiple clock authorities conflicting? |
Do not copy a source-selection threshold or a time-step policy from an unrelated workload. The consequences of a clock discontinuity differ between a disposable test machine and a system running transaction processing or scheduled work. Discuss the permitted correction behavior with the application owner.
Correct the source path before forcing adjustment
Repair the narrow DNS, routing, authentication or configuration defect demonstrated by the evidence. Keep the approved time-source policy intact. Changing to an arbitrary public server during an incident may bypass the organization's trust design while leaving the original network defect unexplained.
chrony distinguishes gradual correction from stepping the system clock. Review the documented behavior and application impact before using an immediate correction command or changing startup policy. Coordinate a maintenance action when required, and record whether wall-clock timestamps can jump or overlap during recovery.
Verification and a time-health SOP
Observe fresh source measurements and a stable tracking trend over an agreed window. Verify the affected authentication or scheduling workflow without replaying a financial or other irreversible business action. Confirm that source reachability remains healthy after a planned network-policy reload or host restart.
Choose an internal SLO around the time quality actually required by the application and its authentication dependencies. State the observation method and handling of missing measurements. An SLA requires a separate contractual definition. The SOP should include time-source ownership, diagnostic collection, the authority to approve a clock step, coordination with application operators and an escalation path for disagreement between trusted sources.
See Clouvenix linux administration for help defining a reviewed operational scope.
Technical reference
chronyc tracking and source commands, chrony source and correction configuration. Reviewed 19 October 2026; select documentation matching the installed release.