field note
Camera clock drift: why it happens and why it matters
Camera clock drift is quartz running fast or slow between time syncs. Why it grows, why it hides, and what it breaks in evidence, logs, and certificates.
2026-10-24
Camera clock drift is the gap that opens between a camera’s clock and real time whenever nothing is correcting it. Every camera clock runs a little fast or a little slow. Time sync hides that by correcting it over and over, so drift only shows once sync stops working, and by then it has usually been growing for weeks with every health check still green.
The diagnostic playbook (no source, an unreachable source, a disagreeing source, and drift) is in camera NTP time sync problems. This page covers the physics and the stakes: why the clock moves, how fast, what the correction does to a recording timeline, and what a drifted camera breaks downstream.
Why camera clocks drift
A camera keeps time by counting the vibrations of a quartz crystal. The crystal is cut to vibrate at a nominal frequency, and it never quite does. Manufacturers specify how close it gets as a tolerance in parts per million (ppm), and inexpensive timing parts are commonly specified in the tens of ppm. That sounds negligible until you multiply it out.
| Frequency error | Per day | Per 30 days | Per year |
|---|---|---|---|
| 5 ppm | 0.4 seconds | 13 seconds | 2.6 minutes |
| 20 ppm | 1.7 seconds | 52 seconds | 10.5 minutes |
| 50 ppm | 4.3 seconds | 2.2 minutes | 26 minutes |
The table is arithmetic, not a measurement of any camera model. What it shows holds for all of them: a clock left to run on its own does not stay close for long.
Three things push the real rate around.
Temperature. A crystal’s tolerance is specified at room temperature, usually 25 °C, and its frequency shifts as it moves away from that. A camera on a parking lot pole in a Phoenix July, or on a loading dock in a Minnesota January, spends its working life far from 25 °C. Two cameras of the same model can drift at different rates on the north and south walls of the same building.
Age. Crystals age, and their frequency shifts slowly over the years. The rate a camera had at commissioning is not the rate it has at year five.
Power. What a camera’s clock does through a power cut depends on the hardware. Some cameras hold time across a short outage. Others come back at a fixed default date and run from there until their first good sync. Either way, everything the camera stamps between boot and that sync is stamped with a guess.
Sync hides drift until sync stops
With time sync working, drift is corrected continuously and the offset stays close to zero. The moment sync breaks, the offset starts growing at whatever rate that camera drifts, and nothing else about the camera changes. It stays online, keeps producing images, and reports itself healthy.
Sync breaks for ordinary reasons: a firewall cleanup, a time server retired during a refresh, a camera moved to a new VLAN, a factory reset that dropped the setting. None of those events raises a camera alarm. So the camera starts drifting on the day someone changed something else, and it keeps drifting until a person needs its timestamps.
The correction is its own event
When sync comes back, the camera has to get from the wrong time to the right one. Time sync software generally does this one of two ways. Small errors are corrected gradually, by running the clock slightly fast or slow until it catches up. Large errors are corrected by jumping the clock.
A jump leaves a mark. A camera that was running ahead and jumps back stamps the same stretch of minutes twice, once on the wrong clock and once on the right one. A camera that was running behind and jumps forward appears to have a gap in a period when it was recording the whole time. Anything that relies on the camera’s own time, such as recordings on the camera’s SD card, now has a timeline with a fold or a hole in it, and whoever reviews it later has to work out which is which.
Fixing the clock early keeps the correction small enough to be gradual. When a large correction does happen, record when, so the timeline can be explained later.
What drift breaks
The time on the evidence
A camera’s clock reaches recorded video in more than one place. The date and time overlay burned into the image comes from the camera. Recordings stored on the camera are stamped by the camera. Depending on how the recording system is set up, the VMS timeline may come from the camera, from the recording server, or from both. When those disagree, the clip still plays, but the first question about any export becomes which time is right, and every answer after that is weaker for it.
Following someone across cameras
Investigations follow people from camera to camera. If the entrance camera runs 40 seconds fast and the hallway camera is correct, the person appears in the hallway before they walk through the door. An investigator can correct for that once the offset is known. After the fact, nobody knows the offset unless someone was measuring it at the time.
Agreement with other systems
Access control logs the door. The alarm panel logs arming and disarming. Network and identity systems log logins. A camera on its own clock disagrees with all of them, and an incident review that joins video to logs gets slower and more arguable as the gap grows. That includes security events on the camera itself: a burst of failed logins in the camera’s log is far more useful when it lines up with the firewall’s record of where they came from.
Certificates and 802.1X
When a camera checks another system’s certificate, it uses its own clock: the authentication server on an 802.1X port, or the servers it sends events and uploads to. Seconds or minutes of drift rarely matter here, because certificate validity runs for months or years.
Large errors do matter. A camera that comes back from a power cut at a default date years in the past sees every certificate as not yet valid. If it validates the 802.1X authentication server, as it should, it can refuse the network it needs to reach in order to fix its clock, and that loop does not resolve on its own. What certificates do on a camera, and why the clock sits underneath them, is covered in security camera encryption.
Why nobody notices
A drifted camera passes every check that asks whether it is up. It answers, it streams, and its image is fine. Its clock is only wrong relative to something else, so finding drift means comparing each camera’s time against a trusted reference, and then doing it again next week to see whether the gap is holding or growing.
Commissioning checklists and annual audits look once. One reading can show that a camera is off today. It cannot show that a camera which was fine in the spring has been sliding since a firewall change in June.
What fixing it actually means
Setting the clock by hand fixes today. Fixing drift means three things stay true.
- One time hierarchy. Cameras follow the same source as the recording servers, access control, and everything else whose logs get joined to video. A camera that syncs perfectly to a different reference still disagrees with the rest.
- A source the camera can actually reach, from the camera’s own segment, by an address or a name that resolves there.
- A measured offset, per camera, all the time. Drift begins on the day sync breaks. A check that runs continuously turns that day into a same-day alert. A check that runs once a year turns it into a finding in the middle of an investigation.
The step-by-step checks for each failure are in the time sync playbook linked at the top of this page.
Doing this across 500 cameras
On one camera, checking the clock takes two minutes. Across a few hundred cameras on three brands, spread over sites with their own firewalls and their own time servers, nobody compares clocks per device every week, and drift stays invisible to everything that is checking whether cameras are up.
MentatNOC measures clock offset on every camera as a health signal, next to reachability, image health, certificate expiry, and firmware state. Clock drift raises an alert while the offset is still small, cameras that come back from a reset, a swap, or a power cut without good time surface the same day, and the offset history shows which cameras are sliding instead of only which ones happen to be wrong today. It monitors device health, not video.
For an integrator, a drift alert names the camera and site in your own ticketing system, so you can fix the time setting remotely or call the client before their footage is challenged. You can see what the health model covers on the camera fleet health platform page, or watch a fleet get triaged in a live platform demo.