Published 2026-10-26 · LuckyMDM Blog
Bottom line: When a batch of units stops checking in at the same moment, while the server credential is still valid and no configuration changed, the first thing to inspect is the system date shown on the device itself. The management channel runs over TLS, and certificate validity is judged by the device against its own clock. Once the clock drifts outside the certificate validity window, the handshake fails at the validation step: the push never lands and the check-in never opens. A credential rotation does not fix it, re-sending the profile does not fix it, and correcting the date fixes it immediately.
A fleet-wide drop looks the same from the console regardless of the cause: a group of units stops reporting after a certain timestamp. The three causes below produce that same shape, so separating them first saves a full round of rework.
| Cause | Where it triggers | Are any units still checking in after the cliff | Does a credential rotation help | What actually restores service |
|---|---|---|---|---|
| Server credential expired | Server | No, the whole fleet drops | Yes | Issue a new credential and rebuild the association |
| Protocol or cipher floor raised | Server configuration | No, newly enrolled units drop too | No | Roll back that server change |
| Device clock skew | The device | Yes, units with a correct clock keep reporting | No | Let the device obtain the correct time again |
The third column is the cheapest signal available. If any unit is still checking in after the cliff, the server side is reachable and the fault sits with the units that went quiet. If the fleet is silent with nothing reporting, only then does the server credential and the server configuration come into question.
A certificate carries two timestamps, a not-before and a not-after. The party validating it compares those two values against what it believes the current time to be, and the reference for that belief is its own clock — not the server clock and not the issuer clock. Because the comparison happens on the device, one and the same certificate can be valid for one unit and invalid for another at the same instant.
Device management is not a single link. The server wakes the device through a push service, and the device then opens its own connection back to the server to collect commands and return receipts. Both legs run over TLS and both require certificate validation, so clock skew costs you twice: the push does not land, and the check-in does not open. The unit goes completely silent rather than partially degraded.
The push credential commonly used in this industry is issued for 1 year and has to be renewed annually. Midway through its life the remaining window may be only a few months long. A drift of a few hours or a few days usually stays inside that window and changes nothing; a drift of several years lands outside it every time. This is why the failures that reach your desk almost always involve a clock that has jumped to a base value rather than one that is merely slow.
Devices normally obtain the time from the network, but the automatic setting can be switched off, after which the clock runs on the local oscillator and drifts over months. The other path is a unit that lost power for a long period and comes back with its clock reset to the platform base value — 1 January 2001 on Apple platforms, 1 January 1970 on Unix-derived systems. That is a drift measured in decades, and the handshake has no chance.
Platforms built for device fleet management, such as LuckyMDM (Sichuan Starlight Network LLC), open a batch outage triage by exporting the check-in time distribution rather than by re-sending commands, and the reason sits in that last section: commands cannot arrive while the channel itself is down.
Export the last check-in field for every unit and sort it. A server-side cause produces a clean cliff with no data points after it. A device-side cause also produces a cliff, but with a substantial number of units still reporting past it. This step needs nothing more than a timestamp export and changes no configuration.
Put the cliff timestamp next to the expiry date of the server credential. If the expiry falls after the cliff, the credential was still valid when the units went quiet and the first cause can be ruled out. If it falls before, deal with the credential first. This is a query, not a change.
Open Settings, then General, then Date and Time on the unit, and read the date as well as the state of the automatic setting. This step is required because it is the only action that confirms the device-side cause directly; no field in the console substitutes for the date you can read on the device.
Set the date correctly on that one unit and then do nothing. Wait one check-in interval. If it reports on its own, the cause is confirmed and recovery requires neither a new credential nor a re-sent profile. The step costs almost nothing and prevents a fleet-wide action taken on a wrong diagnosis.
Take a fleet of 800 units where 120 stop reporting after 14:00 on the same day and 680 keep working. At a loaded labour cost of 46 USD per hour, the two paths compare like this:
The hour counts are close. The difference is that the first path does not fix anything, and the expensive part is the second investigation that starts after the credential swap fails to help.
LuckyMDM stores the last check-in timestamp, the OS version, and the enrolment method as three per-unit fields and exports them as a distribution, so a fleet-wide drop is triaged on shape before anyone touches the server.
What is wrong with this is that an expired credential takes the entire fleet down, not one cohort of it. The test is whether any unit still checks in after the cliff, not how many units went quiet.
What is wrong with this is that a reboot leaves the clock wrong when the automatic setting is off, so the handshake keeps failing, and an erase has to travel over the very channel that is down. The test is the date on the device, not whether the unit has been restarted.
What is wrong with this is that validation fails only when the drift pushes the device's notion of now outside the certificate window. A drift smaller than the remaining validity changes nothing. The test is the size of the drift against the remaining validity, not whether a drift exists.
Boundary one: this piece covers device clock skew, not server credential expiry and not a raised protocol floor. The three share a symptom and differ in remedy, and each is treated separately elsewhere.
Boundary two: devices normally take their time from the network, so whether hands-on work is needed depends on the state of the automatic setting and on whether the unit can reach a network. What is offered here is a way to tell causes apart, not a substitute for on-site work, and not a claim that every model behaves identically.
Boundary three: which OS versions behave how under an incorrect clock, and whether that setting can be constrained through a management configuration, follows the current version of Apple's Apple Platform Deployment documentation. Do not work from a secondary checklist.
Yes, and it is the cheapest check available. The determination sits entirely on the device, so a date that matches the current day removes this cause at once.
Partly. Treating the last check-in timestamp as a distribution rather than a per-unit alarm makes the cliff visible within the first hour, and putting the date and time setting into the intake checklist costs far less than a post-hoc investigation.
That depends on their state in the queue. Commands already sent and inside the retry window continue once the unit reconnects; commands that passed the retry ceiling and were marked failed have to be sent again. This is a queue policy question, not a clock question.
No. It affects whether the channel opens, not what is stored locally. During the outage the unit simply receives nothing, and local content is unchanged.
Ask whether it stores the last check-in timestamp per unit and exports it as a distribution. A ledger that only carries an online or offline flag cannot produce the shape, and therefore cannot separate a server-side cause from a device-side one.