Someone messaged me last month saying he had installed everything three days earlier and the devices kept flipping between online and offline. He asked whether his computer was too old.
I asked a few questions. Was the cable the original one? No, he had bought a bundle of cheap ones online. Was the phone plugged into a front panel USB port? Yes.
That was enough to locate it. He swapped in an original cable, moved it to a port on the back panel, and the device has been stable since.
When a device goes offline, nine times out of ten it is not a software problem. Here is the troubleshooting path, working from the outside in.
Layer one: cables and ports
This layer clears more than half of all cases and costs the least to check, so always start here.
Take the cable first. This is the most commonly overlooked item: many cheap cables carry power but no data, and look exactly like a working one while doing nothing when plugged in. The test is simple. Swap in a cable you know transfers data. If that solves it, the cable was the problem.
Then the port. Front panel USB ports on a desktop case often run through an internal adapter, and both power delivery and stability are worse than the back panel. With few devices you may not notice. Once you have many, it shows up. Plug directly into a port on the motherboard.
Then the hub. Once you exceed the native port count you need a hub, and there is a common trap here: do not use one that draws its power from the computer. With several devices attached, power runs short and dropouts start happening at random. Use a powered hub, and spread devices across different USB controllers rather than crowding one bus.
One more thing before installation: temporarily disable antivirus, the Windows security real-time protection and the firewall. Turn them back on once everything runs. Security software blocking background services also presents as “the device will not connect”, which is easy to misdiagnose.
Layer two: authorisation and detection
With the physical connection confirmed, look at authorisation.
Trust this computer. Plugging the phone in raises a prompt asking whether to trust this computer, and it must be accepted. Some models only show it once the screen is unlocked, so tapping immediately after plugging in may do nothing. If “do not trust” was selected previously, reset it in settings.
Confirm the computer can see the phone. A third-party phone management tool is the quickest way. If it lists the device, the cable and driver are fine and the issue sits on the software side. If it does not, fix the connection and stop searching inside the software.
Permissions on the phone-side program. All keep-alive options need to be enabled and the floating window must still be visible. Without keep-alive, locking the screen drops the connection. Photo library permission is also needed or the file transfer step will fail. Input method permission is only required if a task involves typing.
The workstation itself. One trap worth knowing: double-clicking the workstation and nothing happening. Install the WebView2 runtime from the same folder and try again. Another: the workstation and the phone-side program must each be signed in with the same account. Signing into only one causes device sync problems.
Layer three: network, for wirelessly connected devices
Devices on WiFi go offline for different reasons. Check these three.
Same network. Phone and computer must be on the same local network. It sounds obvious, but after a router swap or after a phone switches to mobile data, this is the most frequent culprit.
The phone-side program is running. Wireless connections depend on the program staying active on the phone. If the system kills it, the device disappears from the list.
Network load. If other devices on the same network are moving a lot of traffic, downloads, livestreams or large file transfers, control commands stutter noticeably or drop entirely. With many devices, consider separating the work network from the everyday one.
Wireless is inherently less stable than a cable. That is physics. If a few devices carry critical work, put them on USB.
Layer four: the everything-was-fine-and-suddenly-all-offline cases
This layer is the most annoying because it usually happens while you are not watching.
The first cause is an automatic phone system update. A version upgrade can invalidate the connection state and permission settings together, and you find every device misbehaving the next morning. Devices used for automation must have automatic updates disabled. This is mandatory, not optional.
The second is the computer sleeping or restarting on its own. The workstation runs locally, so if the computer sleeps the tasks stop. Machines running long tasks need sleep and automatic updates disabled.
The third is a phone running out of battery. Devices left running for long stretches need continuous power, especially for tasks like video uploads that drain quickly.
Better to be told than to find out
Troubleshooting is what you do afterwards. Getting the problem reported to you is better.
Set an offline alert so you are notified when a device has been down for a while, rather than finding out when you open the workstation.
Run a scheduled sweep. Use Schedule to set a task at a fixed time each day that scans device status and surfaces anything offline. You do not have to watch a screen to know which devices need attention.
Check Execution History after runs. Execution History shows the target device, status and error message for each task. If one device keeps failing, do not look only at that instance. Scroll back and see whether it has been failing all along.
A checklist you can work down
Here is every layer in one table. When a device goes offline, start at row one.
| Order | Check | How to confirm |
|---|---|---|
| 1 | Cable | Swap in an original or MFi certified cable |
| 2 | USB port | Use a port on the motherboard, not the front panel |
| 3 | Phone trust | Unlock the screen and tap trust this computer again |
| 4 | Computer detection | Use a third-party tool to confirm the device is seen |
| 5 | Hub power | Use a powered hub, spread devices across controllers |
| 6 | Antivirus and firewall | Disable temporarily during install and first run |
| 7 | Phone keep-alive | All options enabled, floating window visible |
| 8 | Phone permissions | Photo library granted, input method as needed |
| 9 | Workstation state | Opens, WebView2 installed, same account as the phone |
| 10 | Network, wireless | Same network, phone-side program running |
| 11 | Automatic updates | Disabled |
| 12 | Computer sleep | Disabled |
Back to the person who messaged me. He replaced the whole bundle of cheap cables and bought a powered hub, and has not fought a dropout since. His own summary was accurate: when devices drop, the cause is usually in the part you spent the least on.
If you hit something you genuinely cannot trace, post a screenshot of the device page together with the error from Execution History. That is far more useful than describing it as “it just will not connect”. The install and environment notes are here.
Frequently asked questions
- A device shows offline. What is the first thing to do?
- Check the physical layer. Whether the cable is original or MFi certified, whether it is plugged into a port on the motherboard rather than a front panel, and whether the phone has been told to trust this computer. Those three account for more than half of offline cases and are the fastest to check.
- The cable still charges the phone. Why is it not detected?
- Many cheap cables carry power but no data, and look identical to a working one. The test is simple: swap in a cable you know transfers data. If that fixes it, the problem was the cable and nothing else needs touching.
- I ran out of USB ports, added a hub, and now devices drop constantly. What now?
- Almost certainly power. Use a hub with its own power supply rather than one that draws from the computer. Also spread devices across different USB controllers instead of crowding them onto one bus.
- The phone has been trusted already. Why still no connection?
- Confirm the trust prompt really went through, because some models require the screen to be unlocked first. You can also use a third-party phone management tool to check whether the computer sees the device at all. If that tool sees it, the cable and driver are fine and the problem is on the software side. If it does not, fix the connection first.
- Devices go offline again after a restart. Why?
- Two common reasons. The phone-side program is not staying alive, which usually means the keep-alive settings are not all enabled. Or the phone locks its screen and drops the connection. Enable all keep-alive options on the main program and confirm the floating window is still visible.
- How do I troubleshoot a WiFi connected phone?
- Check in order: whether phone and computer are on the same network, whether the program on the phone is still running, and whether other traffic on the network is saturating it. Wireless is inherently less stable than a cable. When you have many devices, put the critical ones on USB.
- Everything was fine overnight and all devices were offline in the morning. What happened?
- Check whether the phone installed a system update. A version upgrade can invalidate the previous connection state and permission settings together. Devices used for automation must have automatic updates disabled. That is not optional. The other candidate is the computer sleeping or restarting.
- How do I avoid finding out a day late?
- Set an offline alert so you are told when a device has been offline for a while, rather than discovering it when you next open the workstation. You can also schedule a daily sweep that scans device status at a fixed time and surfaces anything that is offline.
Get the devices stable first
Work down the checklist and most offline problems resolve
Software is completely free and runs on your own computer.