The app opens. The fleet list appears. But the numbers feel stale, a restart command goes nowhere, and remote control will not connect. Nothing is wrong with your phone. The centre of the system has stopped — and the app, honestly, is just the messenger.
Understanding this failure starts with the architecture from the core guide: agents talk to the server, the app talks to the server, nobody talks around it. When the Endpoint Central server or its service is down, every layer degrades in a characteristic way. Recognising the pattern quickly — instead of reinstalling the app or blaming the phone — is the skill this page builds.
A dead server announces itself through staleness before it announces itself through errors. Data that does not refresh. Computers shown online that you know are off. Actions — restart, scan, wake — that accept your tap and then simply never complete. Remote sessions that hang at connecting. Compare that with a phone-side problem (only your app fails; a colleague's console works fine) or a network problem (the VPN will not connect at all). The decisive test takes one minute: can the web console be reached, from any machine? If the console is down for everyone, stop debugging phones. The patient is the server.
Be clear about the boundary, because users will ask. The app cannot control anything — no remote sessions, no restarts, no shutdowns. It cannot change anything — no approvals, no deployments, no new scans. It cannot even see anything new — what it shows is the last state the server reported. There is no offline mode that queues your commands for later delivery, and pretending otherwise to a frustrated manager only buys a worse conversation later. What still works is everything that never needed the server: the users' PCs run normally, and the agents installed on them simply wait, retrying their connection on their own schedule. Management has paused; the office has not.
Recovery follows the architecture in reverse. First, the server machine itself: is it on, is it reachable on the network, is the Endpoint Central service running? Most server-down stories end at one of those three. Second, the route: if the server is healthy on the LAN but the app still fails from outside, the problem has moved to the VPN or the Secure Gateway — check that layer next. Third, confirm with a live test from the app: refresh the fleet, run one small action on one machine. Only then tell the office it is back. And afterwards, add the outage to your alert policy: the server failing is precisely the class of event your phone should interrupt you for — the next page-set page on notifications explains why it tops the list.
Watch the app running a live fleet in the full video — and you will know exactly what normal looks like when a bad day comes.
▶️ Watch Full VideoAlmost certainly not. Stale data plus actions that never complete is the signature of a server-side problem. Test the web console from any computer — if it is down too, the server or its service needs attention, not your phone.
No. Users keep working normally. Only management pauses — no new patches, approvals or remote sessions — until the server returns. The agent on each PC waits and reconnects on its own.
No — the app acts through the server in real time and offers no offline queue. Restore the server first; then issue the commands. Anyone who needs a restart urgently during the outage gets the old-fashioned answer: a person at the machine.