# Critical ClockDriftDetector error

**URL:** <https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [December 19, 2024, 6:21pm UTC](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055 "2024-12-19T18:21:02Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Charissa\_Luong](https://avatars.discourse-cdn.com/v4/letter/c/bcef8e/32.png) [@Charissa\_Luong](https://forum.inductiveautomation.com/u/Charissa_Luong)\
**Post date:** [December 19, 2024, 6:21pm UTC](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055/1 "2024-12-19T18:21:02Z")

</div>

Something went VERY wrong and I have no idea how the time got changed by a month.

I logged in today to look at some trends and noticed 95% of my tags were not recording trends. Went onto the gateway and didn't see any issues with quarantined data or anything in my cache. But then noticed that there was a weird date in my log.

How did this happen and how can I fix it?

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/1/f113071f96d9099ac2ef6579451049d93fb8d7b3.png)

 ![iamge 2](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/5/95e71767fa7ac24f7f22c920ba190c645574a788.png)

---

<div class="post-metadata">

**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\
**Post date:** [December 19, 2024, 6:28pm UTC](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055/2 "2024-12-19T18:28:26Z")

</div>

1. What OS is the gateway running on?
2. What's the OS clock reading?
3. What's the OS timezone?
4. Are you keeping the OS clock in sync with an NTP server? Which one?

---

<div class="post-metadata">

**Author:** ![Charissa\_Luong](https://avatars.discourse-cdn.com/v4/letter/c/bcef8e/32.png) [@Charissa\_Luong](https://forum.inductiveautomation.com/u/Charissa_Luong)\
**Post date:** [December 19, 2024, 6:38pm UTC](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055/3 "2024-12-19T18:38:22Z")

</div>

1. Server 2019 Datacenter version 1809 build:17763.6532
2. OS Clock reading is correct since we discovered the issue.
3. timezone:UTC-8 Pacific -- Set time automatically = on Set time zone automatically = off
4. NTP server used: [ca.pool.ntp.org](http://ca.pool.ntp.org)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [December 19, 2024, 6:50pm UTC](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055/4 "2024-12-19T18:50:06Z")

</div>

You can't get a log entry in 2025 unless date and time on your OS is badly broken.

Consider not using Windows. Its NTP client does time warps when given bogus data. (Instant change to new time.)

Linux' NTP client only does a time warp on initial boot. Later bogus data starts a slow skew adjustment that usually doesn't make a big change before the bogus data disappears on the next NTP poll. (And skews the small change back to proper.)

Windows is simply dumb in this case. (Among others.)

Or use a local NTP time source that won't give you bogus data, like a GPS receiver.

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [December 19, 2024, 7:03pm UTC](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055/5 "2024-12-19T19:03:08Z")

</div>

All of what @pturmel said. Especially the GPS receiver for the time server.

However, if you are stuck on Windows (unfortunately, that still happens), Meinberg's [NTP Software](https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable) is a good alternative over W32Time.

---

<div class="post-metadata">

**Author:** ![Charissa\_Luong](https://avatars.discourse-cdn.com/v4/letter/c/bcef8e/32.png) [@Charissa\_Luong](https://forum.inductiveautomation.com/u/Charissa_Luong)\
**Post date:** [December 19, 2024, 7:12pm UTC](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055/6 "2024-12-19T19:12:29Z")

</div>

Thanks for the feedback! It looks like this is the reason that the time got messed up. Looking at the server logs confirms it.

The main problem though is that I think it's broken the historian settings or maybe the partitioning of the historian. Is there a way to fix it?

The partition manager has a table for 2025\_01 (Jan 2025) as seen on the second line in the logs.

---

<div class="post-metadata">

**Author:** ![Charissa\_Luong](https://avatars.discourse-cdn.com/v4/letter/c/bcef8e/32.png) [@Charissa\_Luong](https://forum.inductiveautomation.com/u/Charissa_Luong)\
**Post date:** [December 19, 2024, 9:55pm UTC](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055/7 "2024-12-19T21:55:23Z")

</div>

FYI I restarted the server and the data history started collecting normally again. Lost data was not backfilled.
