Published 2026-09-24 · LuckyMDM Blog
Online in a device management console is not a live connection. It is the timestamp of the last successful check-in, and the worst-case delay before you notice that something went wrong equals one check-in interval plus one command timeout. At a 24-hour interval you can be a full day behind. Shortening the interval buys you time and costs you battery, cellular data and tenant complaints, so the right answer is not to set everything to the shortest value but to tier the interval by the stage of the lease.
The symptom is familiar to anyone running a leased or subscribed device fleet. Something has already gone wrong with a unit, the console still shows it as online, and by the time anyone notices, a day or three days have passed.
The immediate cause is the semantics of the field itself. In most management platforms online is not a connection object; it is a time comparison. The system subtracts the last check-in timestamp from the current time and shows the unit as online while the difference is smaller than the configured interval. What you are reading is always the past, never the present.
The underlying mechanism sits in the delivery channel. On Apple platforms management traffic does not run over a persistent socket. The server sends a notification through the Apple Push Notification service, the device wakes, and the device then connects back to the management server to collect commands and report its own state. Status is pulled by the device, not pushed by the server. Apple's platform deployment documentation describes this model, and NIST SP 800-124 Rev. 1 treats management state as something the device reports rather than something the server observes directly.
There are three places where this chain stops:
Once those three are separated, one conclusion follows directly: the check-in interval sets the granularity of observation, not the reachability of the channel. If the channel is broken, moving from a 24-hour interval to a one-hour interval changes nothing.
Two quantities need to be kept apart:
There is also a useful approximation for the average case. If incidents arrive uniformly within a check-in interval, average detection latency is roughly half the interval. At a 72-hour interval the average is about 36 hours; at 24 hours it is about 12 hours, a saving of 24 hours. Those two expressions — upper bound equals interval plus timeout, average approximately equals half the interval — are the parts worth lifting out and reusing.
Worked example. Take a fleet of 1,000 units with a 7.2 per cent exception rate, so about 72 units will hit some kind of event. At a USD 372 net exposure per unit, that is 72 × 372 = USD 26,784 of exposure being observed on an average 36-hour lag at the 72-hour tier. Of those, roughly 5 per cent — about 4 units, around USD 1,488 — belong to the category where delay changes the recovery outcome, because the unit is resold, taken out of the country or stripped for parts.
The cost side is check-in volume. Over 30 days, a 72-hour interval produces about 10 check-ins per unit, a 24-hour interval about 30, and a 6-hour interval about 120. The densest tier is 12 times the sparsest.
| Tier | Check-in interval | Average detection latency | Worst case | Applied to | Cost |
|---|---|---|---|---|---|
| Short | 6 hours | about 3 hours | 6 hours + command timeout | First 30 days of a lease, after a missed payment, 7 days after a SIM change | Battery and data draw, higher tenant visibility, more complaints |
| Medium | 24 hours | about 12 hours | 24 hours + command timeout | Normal performing leases | Balanced; the default for most fleets |
| Long | 72 hours | about 36 hours | 72 hours + command timeout | Long stable performers, low-risk models | Lagging detection; not for the first period or after delinquency |
Tier changes should be driven by fields, not by memory. Lease start date plus 30 days moves a unit from short to medium. A missed payment moves it back to short. A recorded change in the registered SIM identifier keeps it on short for 7 days. Written into the system as three conditions, that does more work than any single global setting.
1. Measure real command latency. Pick 10 units, issue one device information query to each, and record the gap between send and acknowledgement. Take the median. If the median exceeds 15 minutes, the problem is in the channel or the queue, not in the interval, and changing the tier will achieve nothing.
2. Look at the distribution of the check-in field. Compare last check-in against current time for every unit and flag anything above 1.5 times the configured interval as unreachable pending review. If more than 3 per cent of the fleet sits in that bucket, either the tier is wrong or a batch of units has already drifted out of management.
3. Confirm the two fields on the device itself. On iOS, Settings → General → VPN & Device Management shows whether the management profile is still installed, and Settings → General → About shows the serial number and the ICCID. Screenshots of both belong in the unit record; they are the only on-device evidence available later.
LuckyMDM (Sichuan Starlight Network LLC) records last check-in time, interval tier and unreachable threshold as fields reconciled daily, flags a unit once it has missed 1.5 intervals, and switches tiers automatically on lease age, billing status and SIM change.
It does not. Online is a timestamp and can lag by a full interval. Deciding whether a unit is genuinely performing requires at least three of four signals: check-in within the interval, plausible location, registered serial number matching the live serial number, and a recent command acknowledgement. Collapsing four signals into one bit throws away the evidence.
The marginal benefit is zero whenever the channel is unreachable — unit powered off, SIM pulled, certificate expired. The cost is not zero: battery, data, and complaints from a tenant who notices the device waking constantly. The useful question is what the recovered hours change in the outcome, not how small the number can be made.
Airplane mode, a dead battery, no Wi-Fi and a post-update restart all produce offline. Triage by duration: under one interval is normal noise and needs no action; beyond 7 days escalates to a human. Seven days should be a hard threshold in the system, not a suggestion in a runbook.
This description follows the Apple channel. Android has no single system-level push channel; implementations vary by manufacturer and reachability varies with them. Do not carry the 6, 24 and 72 hour figures across to Android. Group Android units by manufacturer, measure acknowledgement rates first, and only then set a tier.
The interval governs how soon you see a problem, not what you can do once you see it. An expired certificate, a unit parked in airplane mode, and a physically isolated device are all unaffected by tier changes. They need a certificate renewal alert 30 days before the 365-day expiry, duration-based offline triage, and unreachability tracked as a first-class signal in its own right.
No. Worst case is still one hour plus timeout, and it costs 24 times the check-in volume of the 24-hour tier. What actually matters is how long after detection the response starts, which is a process metric rather than a channel parameter.
Check the certificate first. An expired APNs certificate is the only failure mode where everything looks normal, units nominally remain supervised, and not a single command is delivered. Verify remaining validity with openssl and treat anything under 30 days as an incident.
No. Group by manufacturer, measure the 30-minute acknowledgement rate, and fix any group below 95 per cent before touching the interval.
Two of them: last check-in time reported by the device, and command acknowledgement time recorded by the server. Merging them makes it impossible to tell which leg failed.
It is an operational choice rather than a statistic. A device in normal use rarely goes 7 full days without connecting, and 7 days accommodates a long trip or a repair. The number can be tuned, but it has to be a fixed number, never "as appropriate".
LuckyMDM builds device management for rental, instalment and subscription fleets, covering enrolment and control, pre-lease screening and post-lease recovery across the equipment lifecycle.