Time synchronization and clock failures
Diagnose host clock drift without confusing guest time zones with infrastructure time.
Time synchronization supports certificate validation, signed event freshness, lease evaluation, and cross-component diagnosis. A guest display time zone is separate from the host's synchronized clock.
Host policy
Open Fleet → Nodes → Node → Health → Time to inspect source and offset. Correct the node's Linux time service on that host, then confirm the next reported observation; the console does not set a guest display time zone.
Nodes must use an approved time source and report synchronization state during admission. Installation policy defines the permitted offset and source requirements. An unhealthy time condition can exclude new placements without stopping guests already running on the host.
A manually corrected clock that continues drifting does not establish a healthy source. Check source reachability, synchronization service state, virtualization clock support, and the host's observed offset over time.
Certificates and signed requests
A clock too far ahead can treat a valid certificate as expired. A clock too far behind can reject its not-before time. Webhook receivers can reject correctly signed deliveries when their own clock lies outside the permitted freshness window.
Correct the clock or its source. Disabling certificate verification or enlarging every signature tolerance hides the dependency failure and changes the trust model of unrelated integrations.
Operations and journals
Infrastructure records distinguish source event time from receive time. A clock jump can make source events appear to precede their initiating operation or arrive far out of sequence. Use operation identity and authoritative state, not timestamp sorting alone, to establish execution outcome.
Do not infer that a lease is safe to reuse because a local clock was moved forward. Writer ownership must follow the storage and recovery protocol, including fencing when the previous owner is unresolved.
Guests and migration
The image chooses guest time services and virtual clock drivers. A host migration preserves droplet identity but can expose guest clock-driver or synchronization problems if the image was not prepared for the pool's supported hardware contract.
Inspect the guest's own time source after migration when applications report expired sessions or large time changes. Changing its display time zone does not fix an unsynchronized underlying clock.
Restricted environments
An offline installation needs an internal time source available during a control-plane or identity-provider incident. Record that dependency in the recovery order. A time service hosted only on the same failed node fleet can obstruct certificate and agent recovery.
See offline installations, certificate rotation, and webhook verification for the affected operating procedures.