I saw a similar thread about the photon describing it as being online in every way but showing as Offline in the iOS app. I have that same behavior in the Electron I just received.
Although I'm not sure about the photon, I'm pretty sure about the electron. Just checked with the team, and with the Electron there's no real 'online' of 'offline' due to the connection protocol.
This is from the change log blogpost (probably also in the docs):
“Last Heard” helps you know the status of your Electron.
Because UDP is a connectionless protocol, the concept of a device being “online” or “offline” is fundamentally different for the Electron than for the Photon and Core. If you inquire your devices’ status in Particle Build/Dev or by issuing aparticle listcommand in the CLI, you’ll be presented with the “last heard” status of each device, which represents the last time the Cloud successfully received communications from your device.
That's all to say that there isn't a definitive way to tell if a device is online, unless you hear from it, or poll it for its status, both of which use data and thus money.
As far as the app goes, hopefully a 'last seen' function will be introduced soon to address this issue.
My Electron has been turned off for the past 90 minutes, and running the "particle list" command still shows my device as "online", which obviously is not true. It does not output a specific 'last heard' timestamp, either. Is there something I'm doing wrong to check the status of the device via command line? Thanks.
Thank you, that explains it. I hope they add a feature where you can poll the device manually from the app to update its status.
This topic is a little dated, so I thought I’d ask if there has been any change to this situation with regards to not being able to reliably determine the online/offline status of an Electron?
Nothing about the protocol has changed , so there’s very little that can be done about that. If you want to know if your device is online, you’ll have to actively ‘poke’ it. Call a function or a variable to do so.
Ok, thanks for the update.
I just thought that with the keepAlive() function, the cloud would be aware that it hadn’t received a UDP packet for a while (23 minutes in the default case) and would assume device offline and mark it so.
Then when it next receives a keep alive ping it could flip the status accordingly.
An added bonus would be to be able to specify your custom time between keepalives per device to the cloud.
Maybe food for thought for the protocol team? 
That keepAlive() actually only goes to the cell tower but doesn’t reach the cloud, so this doesn’t change anything - and even if it did, it still would not allow to know the state between pings.
BTW, the most common issue with my Electrons is that they are reported as online tho’ they are not - I’ve hardly ever seen the other way round.
Aah, ok. The docs indicates that the function helps maintain the connection between the cloud and the device, so I expected that the udp keep alive packet traversed between those two end points. My bad.
I agree that the state would not be known, but figured reasonable assumptions could be made. Anyway, this state problem is still a hurdle to overcome somewhere in my future, not just yet.
Agreed. That is the situation that I am seeing and was wondering if it was normal. Seems like it is for now.