We’ve listed a few ways to find out how long your computer has been up and running before. But how can we find out the same information on a remote computer? It could be helpful to know how long the remote computer has been running before informing the remote user and ask them politely that it’s time to reboot their computer.
Here are a few ways to find out.
Command Line
SystemInfo is a built-in Windows command line that displays some basic info about not only about your local computer but any remote computers on the same network as well. Simply use the /s switch in the command followed by the name of the remote computer, like below.
SystemInfo /s Remote_Computer | find "Boot Time:"
It’s easy and pretty straightforward but the drawback is that it only displays the “System Boot Time“, indicating when the computer was booted last time, instead of the “System Up Time”, indicating how long the computer has been running. It’s more like an indirect answer to the question but you can get a rough idea from there.
Sysinternals
The popular Sysinternals Suite has a command called PSInfo that can pull the same info and directly displays the Uptime info with uptime switch.
PSInfo Uptime \\Remote_Computer
The drawback of using Sysinternals tools is that you will need the Remote Registry service up and running. Or, you will get the error message like below.
PowerShell
The most efficient way is probably just to use PowerShell cmdlets. Use the Win32_OperatingSystem WMI class with the -ComputerName switch to pull the LastBootupTime property from a remote computer and then subtract from the value of the current date/time that comes from Get-Date.
(Get-Date) - (Get-CimInstance Win32_OperatingSystem -ComputerName Remote_Computer).LastBootupTime
And of course, you will need to replace Remote_Computer with your real remote computer name in the above samples.
If you only know the remote computer IP, you will need to use Get-WimObject cmdlet instead. You will also need to use .Net’s ManagementDateTimeConverter to convert the timestamp format.
(Get-Date) - [Management.ManagementDateTimeConverter]::ToDateTime((Get-WmiObject Win32_OperatingSystem -ComputerName $computer).LastBootUpTime)
These don’t show the real uptime. Windows 10 uses a hybrid shutdown. It logs off all users, and then hibernates.
How do you get that uptime?
If it goes down as hibernate, it shouldn’t be counted as a real shutdown. So when it wakes up again, the uptime should continue. I will find a machine to try but technically speaking, it should be the case.
Actually not even powering off the computer will reset the UPTime.
If you check with taskmanager will see that the uptime is not reset after power off the computer, since its not a real power off in windows 10
Restart is the only that will reset the uptime counter.
Good observation. Thanks for pointing it out. Remember that Fast Startup option? It’s the one that is messing up with our Uptime.
Or you can turn off the Fast Start option in Windows 10 to prevent it going into hibernation mode at the very end of a shutdown. Has some drawbacks, but as an admin it’s worth it to us to have a full shutdown completed.
Yes, totally agree.
Why Not just change the power button functionally from Hibernate to actually Shut Down, in Edit Power Plan. that still works…
Not when Fast Shutdown is enabled. When enabled, it doesn’t matter HOW you shutdown, it’s still effectively a hibernate mode.
When fast-startup is enabled, holding down shift while clicking Shutdown does a true shutdown and power off.
systeminfo | find “System Boot Time:” Will give you boot time. Calculate from there.
Your command PSInfo Uptime \Remote_Computer is missing an extra \ at the front
It should read: PSInfo Uptime \\Remote_Computer
A note on the PowerShell option: it subtracts the boot time of the remote system from the current time on the local system. If the clocks on both systems are not aligned, this could give an inaccurate result.
(For example, perhaps the remote system has time synchronization disabled, and its clock has drifted over time, and it’s now 27 minutes off. Assuming your local system’s clock is accurate, the uptime calculated from this command will be off by 27 minutes from the actual uptime of the remote machine.)