← Back to blog

5 Built In Windows 10/11 Uptime Checks and Event Viewer Verification

September 1, 2026
5 Built In Windows 10/11 Uptime Checks and Event Viewer Verification

Open Task Manager, click Performance, then CPU. The Up time field tells you exactly how long your PC has been running, no math required. Prefer the keyboard? Open PowerShell and type Get-Uptime. Both give you the answer instantly, but they don't always agree with each other, and the rest of this guide explains why.


TL;DR:

  • Windows uptime can be checked quickly with Task Manager or PowerShell, but different tools may report slightly different results due to various factors.
  • Uptime commands like systeminfo and WMIC report kernel boot time, which requires subtraction from the current time for accurate duration, while Get-Uptime provides a direct duration.
  • Fast Startup uses a hibernation-like state that preserves kernel sessions, often causing uptime counters not to reset after shutdowns or restarts.
  • Event Viewer logs restart and shutdown events, offering an authoritative record to verify suspected discrepancies or suspicious reboots.
  • For managing multiple machines, PowerShell remoting and scripting enable scalable, automated uptime monitoring, but manual checks suffice for one-off troubleshooting.

Table of Contents

Five reliable ways to check Windows uptime

You have five built-in options, and none require installing anything. Which one you reach for depends on whether you're troubleshooting one PC or checking a dozen.

  • Task Manager: Right-click the taskbar, open Task Manager, go to Performance → CPU, and look at the "Up time" line near the bottom right. This is the fastest built-in method for most people, and it works identically on Windows 10 and Windows 11.
  • Settings or Control Panel: Open network adapter status and check "Duration." This tracks how long the current network connection has been active, not the operating system itself, so treat it as a fallback, not ground truth.
  • Command Prompt: Run systeminfo | find "System Boot Time" or wmic os get LastBootUpTime for a timestamp you can compare against the current time.
  • PowerShell: Run Get-Uptime for a direct TimeSpan, or use (Get-Date) - (gcim Win32_OperatingSystem).LastBootUpTime for the same calculation done manually.
  • Event Viewer: When a number looks wrong, this is where you go to confirm what actually happened, restart, crash, or just a long stretch of work.

Task Manager wins for a quick glance. PowerShell wins the moment you need to log or script anything. Practical how-to guides across the web land on this same short list, and nearly all of them point to PowerShell once automation enters the picture.

Copy these commands and read the output correctly

Command Prompt and PowerShell each solve the uptime question a little differently. Here's what to run and how to read what comes back.

  1. systeminfo | find "System Boot Time" returns a full timestamp, something like 4/12/2026, 8:03:15 AM. That's when Windows last booted, not how long it's been running. You still have to subtract that timestamp from the current time to get elapsed uptime.
  2. wmic os get LastBootUpTime returns a raw, condensed timestamp like 20260412080315.500000+000. It's the same underlying data as systeminfo, just uglier and faster to grab in a script. Note that WMIC is deprecated in newer Windows builds, so if it stops responding on your machine, that's expected, not a bug.
  3. (Get-Date) - (gcim Win32_OperatingSystem).LastBootUpTime does the subtraction for you and returns a TimeSpan, formatted as days, hours, minutes, and seconds. Read it left to right: 2.05:33:12 means 2 days, 5 hours, 33 minutes.
  4. Get-Uptime (PowerShell 6 and later) skips the whole calculation and hands you a clean TimeSpan directly. Add Get-Uptime -Since if you want the actual boot timestamp instead of the duration.

None of these four commands require an elevated (Administrator) prompt. The one exception: if your organization has locked down WMI or CIM access through Group Policy, you may need elevated rights or it will simply fail silently.

Pro Tip: Run Get-Uptime and wmic os get LastBootUpTime back to back. If they roughly agree, trust the number. If they're wildly different, skip ahead to Event Viewer before you assume anything.

Why your uptime checks don't always match

Different tools ask fundamentally different questions, which is why they sometimes hand you different answers.

  • Kernel boot time (what WMI and systeminfo report) marks when the OS core last initialized.
  • Network adapter Duration tracks connection time, which resets on a driver hiccup or Wi-Fi reconnect, with zero relation to how long Windows has actually been running.
  • Get-Uptime's tick-based timer and WMI's recorded LastBootUpTime property can drift slightly from each other because one counts ticks and the other reads a stored value.

The biggest source of confusion, though, is Fast Startup. It uses a hibernation-like state that preserves the kernel session even after you click "Shut down." Your PC looks freshly off, but the uptime counter never actually reset. For a quick sanity check, trust Task Manager or Get-Uptime. For an audit where the exact reboot history matters, only Event Viewer gives you the real story.

Confirm what really happened with Event Viewer

When an uptime number seems suspicious, too high, too low, or inconsistent between tools, Event Viewer settles the argument. It logs every startup and shutdown event with a timestamp, which no single uptime command can fully replicate.

  • Open Event Viewer, expand Windows Logs, and select System.
  • Filter by Event ID 6005 (startup), 6006 (clean shutdown), 6008 (unexpected shutdown), and 41 (Kernel-Power, usually a crash or hard reset).
  • Cross-reference timestamps against recent Windows Update installs or scheduled restarts to rule out patch-driven reboots.
  • If you're escalating to IT, export the filtered log along with the exact command output you started with.

Pro Tip: Event ID 41 with no matching 6006 right before it usually means a crash or power loss, not a graceful shutdown. That distinction alone can save a support technician an hour of guessing.

Scriptable checks for admins managing multiple machines

Checking one PC by hand is fine. Checking twenty is a different job, and PowerShell handles it well.

  1. Use Get-Uptime -Since to grab the boot timestamp in a clean, sortable format, ideal for logging into a CSV over time.
  2. Pull the same data with (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime, which works on older PowerShell versions where Get-Uptime isn't available.
  3. For remote machines, wrap either command in Invoke-Command -ComputerName $list -ScriptBlock { Get-Uptime } and collect results into an array or export them straight to file.
  4. Once you're checking more than a handful of devices on a recurring basis, PowerShell Remoting scales better than logging into each one individually, and it fits naturally into existing help-desk scripts.

For anything beyond occasional spot checks, a dedicated network and device monitoring setup, rather than a stack of scheduled scripts, usually saves more time than it costs.

When a manual check is enough, and when it isn't

A single uptime check answers a single question: has this machine restarted recently? For one-off troubleshooting, Task Manager or a quick PowerShell command settles it in seconds, and there's no reason to overthink it.

Where manual checks fall short is pattern recognition. If a machine's uptime keeps resetting unexpectedly, or if slowdowns keep showing up after long stretches without a restart, a single snapshot won't show you that trend. Excellent for triage, weak for anything recurring. That's the actual limit, not a knock on the commands themselves, they just weren't built to correlate uptime with CPU, RAM, or disk behavior over time. If you're chasing a pattern rather than answering a one-time question, pair uptime with broader system resource monitoring instead of running the same command every morning.

— Ian

An easier way to keep an eye on uptime and performance together

Running Get-Uptime once tells you how long a machine has been on. It doesn't tell you whether that uptime is quietly dragging down performance through memory leaks, runaway background processes, or startup bloat. Tempered tracks uptime alongside live CPU, RAM, GPU, and disk metrics on Windows 10 and 11, then flags the actual cause when something's off, in plain language, with a clear undo path for every change it suggests.

Tempered

That combination matters most once you're past a one-time check. If your PC has been up for a long time and startup feels sluggish, Tempered can tell you whether that's normal or whether a specific process is the reason. It's built for exactly the readers who found this guide: people who want real answers, not vague "optimization" promises. If long uptime keeps you guessing about what's actually slowing your machine down, try Tempered and let it show you what's really happening under the hood.

Sources

For deeper technical detail, Microsoft's Get-Uptime documentation covers syntax and parameters directly from the source. The GeeksforGeeks walkthrough and HelpDeskGeek's guide both cover every built-in method with screenshots.