On the PC I'm writing this on, Windows says it has been up for 3 days, 6 hours and 18 minutes - since 1:09 PM on October 6. That's not true. I shut it down just after midnight on October 7, and it has been started again on each of the last three mornings. Windows still counts from the 6th, and most of the ways to "check uptime" will repeat that number back to you.
Below are the five ways to read a Windows machine's uptime, each run on that PC, then the reason the number is so often wrong on a desktop - and how to see the real last boot.
1. Task Manager
Press Ctrl+Shift+Esc, open the Performance tab, select CPU, and read Up time under the graph. It's the quickest way, and it's the number most affected by Fast Startup (below).
2. Command Prompt: systeminfo or net statistics
systeminfo | find "System Boot Time"System Boot Time: 10/6/2026, 1:09:29 PMsysteminfo takes a few seconds, and the label is translated on non-English Windows, so find "System Boot Time" only matches on an English system. A faster one:
net statistics workstation | find "since"Statistics since 10/6/2026 1:09:36 PMThat's when the Workstation service started - seven seconds after boot here - which is close enough for "how long has this been up".
You'll also find wmic os get lastbootuptime in older guides. WMIC is deprecated and Microsoft is removing it from Windows 11, so don't build a script on it; use PowerShell.
3. PowerShell (any version)
$boot = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
$up = (Get-Date) - $boot
"Up {0}d {1}h {2}m (since {3})" -f $up.Days, $up.Hours, $up.Minutes, $bootUp 3d 6h 18m (since 10/6/2026 1:09:29 PM)This works in the Windows PowerShell 5.1 that ships with Windows 10 and 11. If you've installed PowerShell 7, there's a cmdlet for it: Get-Uptime, or Get-Uptime -Since for the boot time. It doesn't exist in 5.1 - on this PC Get-Command Get-Uptime finds nothing - which is why so many copied scripts fail with "not recognized".
4. A remote server, or several
Get-CimInstance Win32_OperatingSystem -ComputerName SRV01, SRV02, SRV03 |
Select-Object CSName, LastBootUpTimeThis goes over WinRM, which is on by default on Windows Server and off on Windows 10 and 11 - where it fails with "The client cannot connect to the destination specified in the request". For a machine without WinRM, ask over DCOM instead:
$s = New-CimSession -ComputerName SRV01 -SessionOption (New-CimSessionOption -Protocol Dcom)
Get-CimInstance Win32_OperatingSystem -CimSession $s | Select-Object CSName, LastBootUpTime
Remove-CimSession $s5. The event log: every shutdown and restart
Uptime is one number. The System event log has the history behind it:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074,6005,6006,6008} -MaxEvents 20 |
Select-Object TimeCreated, Id, Message- 1074 - a shutdown or restart was started, with which process and user started it, and the reason. The best one for "who rebooted the server".
- 6005 - the event log service started, which happens at every boot.
- 6006 - the event log service stopped cleanly, which happens at every proper shutdown.
- 6008 - the previous shutdown was unexpected: a crash, a power cut, a hard reset.
Why the number is wrong: Fast Startup
Back to the PC that says it has been up since October 6. Its event log has this entry:
2026-10-07 00:42:20 1074 ... has initiated the power off of computer DESKTOP-5LR98GK ...
Shutdown Type: power offA real power-off - and still, every method above reports the boot time as October 6. The reason is Fast Startup, on by default in Windows 10 and 11. With it on, "Shut down" logs you out but hibernates the Windows kernel instead of stopping it, and the next power-on resumes that kernel. As far as Windows is concerned, it never stopped - so the boot time, and the uptime, carry on from the last full start.
The Kernel-Boot log shows which starts were real:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-Boot'; Id=27} -MaxEvents 6 |
Select-Object TimeCreated, Message10/9/2026 9:21:21 AM The boot type was 0x1.
10/8/2026 8:45:47 AM The boot type was 0x1.
10/7/2026 10:33:24 AM The boot type was 0x1.
10/6/2026 1:09:25 PM The boot type was 0x0.0x0 is a full boot, 0x1 a Fast Startup boot, 0x2 a resume from hibernation. So this PC's last full boot was October 6 - Windows is right about that - but it has been powered on from scratch three times since, and that's what "uptime" usually means to the person asking.
What resets the counter:
- Restart always does a full boot. If you want a clean start, restart instead of shutting down.
- Shift + Shut down does a full shutdown, once.
- Turning Fast Startup off makes every shutdown a full one: Control Panel → Power Options → Choose what the power buttons do → Change settings that are currently unavailable → untick Turn on fast startup.
Sleep doesn't reset it either. Windows Server doesn't use Fast Startup, so on a server the uptime from any method above is the real one.
Uptime is not availability
A Windows server can report 90 days of uptime while the thing it's there for has been down since Tuesday: an IIS application pool that stopped, a service that crashed and didn't restart, a certificate that expired, a disk that filled up and took the database with it. Uptime counts from boot. What your users care about is whether the site, the API or the admin panel answers.
To check that once, ask the endpoint itself: the HTTP status checker shows the status code, the timings and whether a monitor would call it up. To know the moment it stops answering, run that check on a schedule - which is what UpWatchr does. It's a free Windows app that checks your sites, APIs and servers on your network from your own PC, and alerts you by popup, email, Telegram or webhook. And if someone quotes you an uptime percentage, the SLA calculator turns it into minutes.
