Check the clock before changing anything
On an Ubuntu VPS that you are authorised to administer, run timedatectl status. The useful distinction is between System clock synchronized: yes and NTP service: active: the latter says a time service is active as recognised by timedatectl, not that the clock has synchronised with a valid source. Record both lines and the incident time before trying to fix an application symptom.
Also run date -u to record the guest's displayed UTC time. The local time and UTC time in timedatectl can differ because of the selected time zone; that difference alone is not clock drift. Neither command compares your VPS with an independent reference. If the clock is wrong enough to affect certificate checks, log correlation or scheduled work, treat that as an incident and keep the original output for diagnosis.
Identify the time client actually running
Check the Ubuntu release with cat /etc/os-release. Then inspect systemctl status chrony.service --no-pager and systemctl status systemd-timesyncd.service --no-pager. An absent unit or an inactive systemd-timesyncd service is not automatically a fault if chrony is the selected client. Ubuntu uses chrony by default from 25.10, while an upgraded system may retain timesyncd; do not infer the active client from the release number alone.
These are read-only checks. Do not install or start a second time daemon merely because one unit is inactive. If your image uses another supported time client, follow that client's documentation and ask the operator responsible for the guest before replacing it.
If chrony is active, read its source and tracking state
Run chronyc -N tracking and chronyc -N sources if chronyc is available and chrony.service is active. In tracking, record the reference time, system time offset, last update and leap status. In sources, a ^* marker identifies the source selected by chrony; a list of names without a selected source is not proof of synchronisation. Keep the complete output and repeat after an interval if the VPS has just booted or lost its network.
Do not treat one small offset as a permanent guarantee or one early System clock synchronized: no as proof of a persistent failure. If the command cannot contact chrony, capture that error and the service status rather than installing packages or resetting the clock as a first step.
If timesyncd is active, check its service evidence
For an active systemd-timesyncd.service, retain timedatectl status and systemctl status systemd-timesyncd.service --no-pager. Ubuntu's documented service output can show the selected time server and a successful synchronisation message. Compare that evidence with the current System clock synchronized line, especially after a restart or temporary network loss.
chronyc is a chrony client: its absence or failure does not diagnose a timesyncd installation. Conversely, a timesyncd status command should not be used to declare an active chrony installation faulty. If neither client is clearly active, establish who manages time on this guest before changing service settings.
Separate a time-zone display issue from failed synchronisation
If UTC is plausible, System clock synchronized: yes is present and chrony or timesyncd has a recent usable source, a different local display usually calls for a time-zone check, not an NTP repair. Record the configured zone rather than moving the system clock to make a log look familiar. If UTC itself is implausible or no source is selected after the guest has had working network access, investigate the time client and its configured upstream path.
For Ubuntu's newer default chrony configuration, Network Time Security can use TCP port 4460 for key exchange as well as UDP port 123 for NTP. A blocked route, unavailable source, very large initial clock error or failed certificate validation can prevent synchronisation, but this guide does not identify which one from timedatectl alone. Other chrony configurations and timesyncd may use different sources. Check the actual configuration with the responsible operator before changing a firewall, source, certificate check or clock.
Give the right evidence to the responsible operator
Send the VPS identifier, Ubuntu release, observed symptom and timestamp with time zone, date -u, timedatectl status, the active service status and either chrony's tracking and sources or timesyncd's status. Include the time of a recent reboot or network change if relevant. Remove private hostnames, addresses or account details from anything shared outside the authorised support channel.
On a self-managed guest, the authorised administrator owns changes to its time client and should follow the applicable Ubuntu guide after confirming the cause. On a managed service, the accepted Order determines which operator may alter guest settings; send the read-only evidence to Novasean and coordinate the change rather than assuming a general managed entitlement. If name resolution is also failing inside the VPS, use the guest DNS diagnosis before attributing an unreachable time source to NTP alone. For interpreting service state after a wider outage, see the systemd status guide.
Common questions
Does NTP service: active mean the VPS clock is correct?
No. It identifies an active time service as recognised by timedatectl. Check the synchronised flag and the active client's source and update evidence before drawing that conclusion.
Should I start timesyncd when it is inactive?
Not if chrony or another intended client is already managing time. Ubuntu can disable timesyncd when chrony is installed to avoid competing clients.
Does changing the time zone repair a clock that is drifting?
No. A time zone changes how a timestamp is displayed. Diagnose the guest's UTC clock and time source separately.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.