Published 2026-10-16 · LuckyMDM Blog
Bottom line: a queued command is not a pending action on the device, it is a row waiting on a server. What turns that row into an outcome is a set of physical preconditions on the device itself, and the three that cause most of the surprises are power, network and device state. Several of them are tiered by the type of action rather than fixed at one value, which is why "we sent it, it should be done" is a sentence that keeps being wrong.
The failure is quiet by design. Nothing in the console changes when a device is at 12 percent battery, sitting on a shelf, or waiting for a passcode that nobody is there to type. The command sits where it was put, and everything downstream of it reads as normal.
Every remote action passes three moments: the moment the console accepts it, the moment the device is reachable and the payload is handed over, and the moment the device actually performs the work. Only the third moment is an outcome.
Consoles often collapse the first two into a single status. That is reasonable engineering and terrible for operations, because the two moments can be hours or weeks apart.
Delivery is recorded on the server because the server knows when it reached the device. Execution is recorded by the device and travels back as a receipt. Between those two facts sits the device's own willingness and ability to carry the action out, and none of that is visible from the console.
If the only number reported is how many commands were accepted, the report describes workload, not state. The number that matters is how many actions reached the executed moment, and that number is pulled from receipts, not from the send log.
Power is not a yes or no gate, it is a table. In Apple's deployment documentation, a user-initiated software update needs roughly 20 percent battery; an automatic software update raises the install threshold to about 30 percent and additionally requires the device to be connected to power to download and prepare the update. For management-driven update deployment, the working figure documented by MDM vendors is a minimum of about 50 percent.
The practical reading: the same device can pass one threshold and fail another, depending on which path the action takes. A unit at 40 percent is fine for an automatic install and not fine for a management-pushed update.
Large payloads, which is to say firmware and operating system updates, are expected to move over Wi-Fi. Cellular is not off the table, but it depends on an explicit permission for the device to use more data on a 5G connection, which is not the default posture on a managed device.
For command-and-control traffic the picture is different: those payloads are small and travel on the push channel the device keeps open, so a device on cellular still receives commands. This is why "the device is online" and "the device can download this" are two different statements.
Three states swallow actions in practice. A device sitting at the lock screen may require a passcode before an installation can begin, so an unattended unit stays parked. A device in the middle of an update is using its resources for that, and receipts for other actions arrive late. A device that has not been through setup at all is not yet part of the fleet in any way that lets it act, regardless of whether its serial number was imported into the register.
| Action | Payload size | Power condition | Network | Device state |
|---|---|---|---|---|
| Small command such as a lock, a status query or a profile push | Small | None beyond normal operation | Push channel, cellular is workable | Powered on and reachable |
| Management-pushed operating system update | Large | About 50 percent battery | Wi-Fi expected | Supervised, passcode may be required |
| Update started by the user | Large | About 20 percent to start | Wi-Fi expected | Setup complete |
| Automatic update install | Large | About 30 percent, power connected to download and prepare | Wi-Fi expected | Setup complete |
What the console shows as a queue is the set of actions the server has accepted. Devices do not reserve work in advance. When a device next checks in, it receives what is waiting and deals with it in whatever order its own logic dictates.
There is no field in a standard management console that reports battery percentage, power connection or passcode state at the moment a command is executed. Those values are readable in some cases, but they are samples from a check-in, not live readings. A device that was at 80 percent at its last check-in can be at 15 percent now.
Consider a 100-unit batch pushed on a Friday afternoon. The units that happen to be plugged in and on Wi-Fi complete; the rest keep the row and finish whenever their conditions are met, which may be the following Tuesday. If the batch is then re-sent on Monday under the belief that it failed, the late-completing units receive it twice. If the action is not idempotent, that second delivery is a real problem. Rework cost is the reason this matters: reversing one wrongly applied action takes about 40 minutes of hands-on time, which at 36 USD an hour is roughly 24 USD per unit, or about 2,400 USD across a hundred units, before counting the disruption.
Three failure modes are often confused, and separating them changes the fix.
LuckyMDM, from Sichuan Starlight Network LLC, keeps requested, delivered and executed as three separate fields on every bulk action and joins them to the last check-in time, because the interval between them is the only place a precondition failure becomes visible: a row that is delivered and never executed is a device condition problem, while a row that is never delivered is a reachability problem.
The working rule across vendors that manage rental and subscription fleets, LuckyMDM included, is to treat every sampled condition as permission to try rather than as a prediction of success.
Acceptance is a server-side event. Until a device checks in and takes the payload, the action exists only as a row. This does not mean the command was lost, only that it has not started.
Thresholds are tiered by path: about 20 percent for a user-initiated update, about 30 percent for an automatic install, and around 50 percent for management-driven update deployment, with a power connection required during download and preparation. Different action, different floor.
Being online means the push channel is open, which is enough for a small command payload. It is not the same as having the bandwidth, the power or the state needed to install something.
Boundary one: this page does not cover legal constraints on what may be sent.
Sending a remote lock or a remote erase involves questions that have nothing to do with battery state. Notice requirements, contract terms and jurisdictional rules are separate work, and a technically perfect delivery does not address them.
Boundary two: preconditions are sampled, not streamed.
Battery state, network and power connection arrive as values collected at check-in. They are useful for building a target list and useless as live telemetry. Any plan that assumes otherwise will be wrong at exactly the moment it matters, which is the moment a large batch is released.
No. Deployment controls decide which update is offered and when it becomes visible; the device still applies its own power and network conditions before installing. The reliable pattern is to make the target list smaller and the window longer, rather than to look for a way around the device's own checks.
Why do some devices in the same batch finish days later?
Because conditions vary per device. Units that are plugged in and on Wi-Fi complete during the window; units on a shelf complete whenever they are next charged and connected. The completion time of a batch is a distribution, and planning against the median is how batches get described as failed.
It can. A command that is still queued on a device that has not checked in will be delivered again when it does check in, alongside the earlier copy. For actions that can be applied twice, confirm by receipt before re-sending.
It sets the upper bound on how stale every sampled condition is. A 4 hour interval means a target list built from check-in data can be up to 4 hours old, which is acceptable for scheduling and too coarse for anything urgent. Shorter intervals cost request volume linearly with fleet size, so tier by device value.
Keep at least these separate and timestamped: last check-in time, check-in interval, platform version and build, and the three action timestamps. Merging delivered and executed into one status field is the single most common register defect here, because it makes a reachability problem and a device-condition problem look identical.