Forum Discussion
Intune On-Demand Proactive Remediation API Reliability for Large-Scale Usage
Adding to my earlier reply on the delivery question, with a disclosure: I work on TFalke, a Windows endpoint management tool, so weigh this accordingly.
The reason this API feels best effort is the delivery model. Intune sends a push nudge and then waits for the device to check in, so anything that interrupts the nudge (sleep, a busy IME, a flaky network, WNS not reaching the device) shows up as a request that never ran, and the 202 response cannot tell you which. That is why the verify through run state and retry pattern is the right way to build on it.
The other model is a persistent connection between the agent and the server, where a command is delivered over an open channel and the device reports success or failure for that exact command. There is no check-in window, so there is nothing to poll for and a missed delivery shows up as an immediate failure instead of a silent gap. TFalke works that way, and it is free for the first 10 devices, so a small test group costs nothing if you want to compare how the two models behave at your scale.
If you stay on Intune, I would still keep the loop from my first reply: log the request time per device, check lastStateUpdateDateTime after a timeout, retry a couple of times, and handle Graph 429s with Retry-After.