Published 2026-09-28 · LuckyMDM Blog
Bottom line: whether a batch command completes depends less on how many commands a server can issue and more on how many devices are actually reachable at the moment you press send. Reachability is not flat across the day; it bottoms out overnight. On a 5,000-unit fleet with a 24-hour check-in interval, a batch sent at 02:00 device-local carries a completion ceiling of 24 hours, while the same batch sent at the reachability peak with three retry waves finishes inside 2 hours. Send time is one of the few variables an operator controls that costs nothing to change.
Most teams treat issued as executed. Between those two events sits a moment the device controls, not the server.
A phone is not a server. Its networking policy is built around battery. In the default configuration, a device that is locked and not connected to power releases its Wi-Fi association after a period of inactivity, and Low Power Mode tightens background refresh and automatic downloads at the same time. At 03:00 a unit sitting on a charger is usually still reachable; the same model on a bedside table often is not. Overnight the fleet splits into two populations while the dashboard shows one blended online rate.
The command path has three legs. The server hands a wake notification to the push channel, the push channel wakes the device, and the device then contacts the server to fetch the command body. The notification itself carries no command content.
The mechanism that catches people out is coalescence. Under one push topic the channel retains only the most recent notification per device. Three retries fired back-to-back at 02:00 do not stack into three chances; the later ones can replace the earlier ones. Whether a retry helps depends on the gap between waves, not on the number of waves.
Even after a device is woken, it only collects the command at its next check-in, and that interval is the check-in period. With a 24-hour check-in, a unit that missed the notification at 02:00 may not collect it until the following night.
So the completion ceiling for a batch is not a fixed number of seconds. It is one check-in interval. Moving the send time into the reachability peak replaces a 24-hour ceiling with a ceiling of retry waves times retry gap.
Deciding when to send on instinct fails, and deciding on a daily average fails too, because an average flattens the overnight trough and the daytime peak into one useless figure. The workable approach is to bucket the last check-in timestamp by hour and plot distinct reachable devices.
| Window (device local) | Typical device state | Reachable units (5,000-unit example) | Guideline |
|---|---|---|---|
| 00:00-06:00 | Locked, mostly unplugged, some in Low Power Mode; OS auto-update clusters here | ~1,050 per hour | Do not batch |
| 07:00-09:00 | Unlocking, commuting, moving between Wi-Fi and cellular | ~3,200 per hour | Small batches only |
| 10:00-12:00 | Unlocked, stable connectivity | ~4,650 per hour | Send window |
| 13:00-18:00 | Stable connectivity, intermittent locking | ~4,400 per hour | Acceptable |
| 19:00-23:00 | Home Wi-Fi, a growing share charging | ~3,800 per hour | Retry waves |
The reachable-unit figures are example parameters. The measurement behind them is fixed: take the last check-in timestamp, bucket by hour, count distinct devices, sample for two weeks and take the median per bucket. Replace the numbers with your own before acting on them.
Parameters: 5,000 units under management, 24-hour check-in interval, manual review at 1 minute per unit, loaded labour at USD 45 per hour, exposure per unit USD 832 (acquisition USD 1,399 less deposit and payments received).
Sent at 02:00 local: the first wave reaches about 21 percent of targets, or 63 of 300. The remaining 237 wait for their own next check-in, so the completion ceiling is one check-in interval, 24 hours. Manual review the next morning is 237 minutes, or 3.95 hours, or USD 178.
Sent at 10:00 local: the first wave reaches about 93 percent, or 279 of 300. Three retry waves at 30-minute intervals add 90 minutes; call it 2 hours with buffer. Manual review is 21 minutes, or 0.35 hours, or USD 16.
The difference is 22 hours of completion time and USD 162 of review labour per event.
Whether 22 hours matters depends on the window it lands in. In device subscription fraud the gap between a unit being collected and being resold is commonly quoted at 24 to 72 hours. Twenty-two hours consumes most of the short end of that range, which is why the window should govern enforcement batches first and routine configuration pushes second.
The reason is not that nobody is watching. It is that device-side state is at its worst there: locked and unplugged, Low Power Mode, and OS auto-update all cluster in the same hours. On Apple platforms, automatic updates install while the device is connected to power and Wi-Fi, and supervised devices can be held back by 1 to 90 days, 30 days by default. A fleet with no deferral policy sees overnight update density climb for a week or two after each major release.
Those are the peaks for debit runs and billing cycles. Channel congestion aside, batch results need a human to follow up, and scheduling a large batch when nobody is following up delays the review along with the command.
Issuing 5,000 commands in one burst complicates server load, acknowledgement backlog and retry triage at the same time. Send 200 to 300 at a time and leave at least 30 minutes between waves so each wave's acknowledgements land before the next one goes out. If waves overlap you cannot tell which wave a straggler belongs to.
Acknowledgements come back in more than two states, and the idle and deferred states are neither success nor failure. Re-sending the whole batch re-notifies devices that already succeeded and overwrites the previous notification on the ones that did not. Triaging by state requires three separate fields: issued, acknowledged and outstanding. LuckyMDM (Sichuan Starlight Network LLC) stores issue time, acknowledgement time and acknowledgement state as three separate fields on every batch command, so outstanding units can be filtered by state and re-sent as one batch.
One, export the last 14 days of check-in timestamps, bucket by hour, count distinct devices, take the median, and plot the reachability curve to locate your own peak.
Two, change the batch template from send-now to scheduled, defaulted to the start of the reachability peak. LuckyMDM exposes send time as a scheduled field rather than an immediate action for exactly this reason.
Three, attach a retry policy to every batch: three waves, 30-minute gaps, retry only outstanding and intermediate states, and open a manual ticket automatically after the third wave.
Four, review monthly. Compute the 30-minute acknowledgement rate per window and drop any window below 90 percent from the schedule. On Android, compute it per OEM, because a blended rate hides the brands that are failing.
Query the last check-in field, bucket by hour and count distinct devices for two weeks. If overnight reachability sits below 30 percent of daytime reachability, the fleet does have an overnight trough and sending at 02:00 is a gamble.
Pick 100 healthy units and send a harmless command, such as a device information query, at 02:00 and again at 10:00. Compare the 30-minute acknowledgement rate. This is the only check that does not require trusting anyone's published numbers.
Confirm whether your console shows issued, acknowledged and outstanding as separate numbers. A single success rate tells you neither which units to retry nor whether the retry worked.
Online rate is usually a daily average or a current snapshot. A fleet averaging 85 percent can sit at 21 percent overnight and 93 percent mid-morning. A high average does not mean the timing is irrelevant; the average conceals exactly the variation you need.
Under one push topic the channel keeps only the latest notification per device. Back-to-back retries do not add chances, they replace each other. Space the waves and retry only what is outstanding.
Send time is an operator variable, not a platform constraint. Attributing the failure to the vendor means never changing the send time and never collecting the 22 hours. There are two variables an operator controls on a batch: what to send, and when.
A server has one timezone; a fleet may span several. A 10:00 send scheduled on server time can land at 03:00 for part of the fleet, so the schedule needs a timezone field per cohort.
With a credible tip that a unit is being transferred right now, or a legal hold in play, do not wait for the reachability peak. Send immediately and open a manual track in parallel. The send window optimises planned batches and is not applicable to emergencies.
Only where it lands inside a window that matters. The quoted resale window for fraudulently obtained devices is 24 to 72 hours, so a 22-hour delay can consume most of the shortest case. On routine configuration pushes it usually does not matter.
You can, and the cost is battery draw on the device and request volume on the server. A shorter interval suits a high-risk tier under a tiered policy. Running the whole fleet at a short interval is expensive for a problem that only affects part of the fleet.
Yes, but it delays a known, bounded set rather than a random one. Waves let you clear acknowledgements batch by batch and see which wave failed, whereas one 5,000-unit burst produces a backlog you cannot triage.
Three, at 30-minute gaps. Beyond that the units are not reachable, further notifications only replace the previous one, and the work belongs on a manual track.
The mechanism holds: push wakes, device fetches. The parameters do not. Channel reachability and acknowledgement latency vary by OEM, so measure acknowledgement latency per brand rather than as one blended figure.