VICIdial time-sync issues: how clock drift breaks call times and stats

A lot of strange VICIdial behaviour comes back to one boring cause: the server clock is wrong. If the system time has drifted, the dialer makes decisions on a time that does not match the real world, and every record it writes carries a timestamp that is slightly off. The symptoms look unrelated until you check the clock, which is why time-sync is worth ruling out early.

How the clock feeds the dialer

Outbound Call times are evaluated against the lead's local time zone, which VICIdial works out from the lead's GMT offset (lead) and the active call-time definition. Inbound and most internal events are evaluated against the server's own clock. So the system asks two questions all day: what time is it here, and what time is it where this Lead lives. Both answers depend on the server having the correct time in the first place.

NTP — the Network Time Protocol — keeps the machine's clock matched to an authoritative time source. On modern Ubuntu boxes the same job is often done by chrony. When that service stops, or was never running, the clock starts to drift. A few seconds is harmless. A few minutes, or a wrong time zone, quietly breaks things.

What drift actually breaks

• Call-time windows. If the clock is ahead, the dialer thinks it is later than it is and may stop dialing a region early, or start before the local window opens. Leads sit unworked in the Hopper when they should be callable.
• Scheduled callbacks. A Scheduled callback is stored as a target time. If the clock is off, the callback fires early, late, or gets skipped entirely because the window it should land in has already passed in the server's view.
• Report timestamps. Every call, Disposition, and Agent session event is stamped with the server time. Drift means your call-detail rows, summary reports, and the live Real-time report disagree about when things happened.
• Recording timestamps. Recordings are named and filed using the server clock. A wrong clock makes recordings hard to line up against the call logs they belong to.

How drift turns into a symptom

flowchart TD
  A[NTP or chrony not synced] --> B[Server clock drifts]
  B --> C[Wrong now time]
  C --> D[Call-time window misjudged]
  C --> E[Callbacks fire early or late]
  C --> F[Report timestamps skewed]
  C --> G[Recordings filed at wrong time]
  D --> H[Leads dialed too early or stranded]

How to check the clock

1. Run date on the server and compare it to a phone or a trusted clock. If it is off by more than a couple of seconds, you have drift.
2. Check the time zone with timedatectl. Confirm it matches the region the box is supposed to serve, and that the offset looks right for daylight saving.
3. Confirm the sync service is actually running. With chrony, chronyc tracking shows whether the clock is locked to a source and how far off it is. With classic NTP, ntpq -p lists the peers it is following.
4. Spot-check a recent report. If recording file times do not match the call rows for the same calls, that mismatch is your drift showing up in the data.

How to fix it

Set the correct time zone first, then make sure NTP or chrony is installed, enabled, and started so the clock stays locked going forward. Once the service catches up, the clock corrects and future decisions and timestamps are right again. Past records keep the wrong stamps they were written with, so note the drift window when you compare old reports.

Clock drift is a common reason agents see a campaign behave as if it is the wrong time of day. A close cousin of this is the morning login puzzle covered in why agents cannot log in before 9AM, where the call-time window, not the clock, is the gatekeeper. For the wider first-response checklist, see the VICIdial troubleshooting playbook.

Keeping a dialer's clock locked and its time zones correct is the kind of housekeeping that is easy to forget until reports stop adding up. VICIfast runs a managed, hardened VICIdial box with NTP set up from the start, live in under 40 seconds. See our plans and pricing.