How to Check Last Reboot Time on Windows Server: 3 Fast Methods

If you manage Windows Server, the three quickest and most reliable ways to answer the simple-but-critical question “When did this machine last reboot?” are the Command Prompt (systeminfo), PowerShell (Win32_OperatingSystem / Get-CimInstance), and Event Viewer (System log Event IDs). Each method has different strengths: speed and simplicity, scriptability and scale, or forensic detail and auditability. This feature pulls together the step‑by‑step procedures, explains what the outputs actually mean, highlights pitfalls you must watch for, and recommends which method to use in which operational scenario. The short how‑to you may have seen elsewhere is accurate, but here you'll get the deeper context and caveats that matter in production environments. (learn.microsoft.com)

Background / Overview​

Knowing the last reboot time is more than trivia: it helps validate patch/maintenance windows, diagnose uptime-related performance regressions, detect unplanned reboots (power loss, kernel crashes), and support security and compliance audits. Windows exposes boot time information in multiple layers:

• A quick summary from the legacy systeminfo utility.
• Structured management data via WMI/CIM (Win32_OperatingSystem.LastBootUpTime), which PowerShell can query and convert into standard DateTime values. (learn.microsoft.com)
• Event log entries that record what happened and who or what requested a shutdown or restart (Event IDs such as 1074, 6005, 6006, 41 and others). (learn.microsoft.com)

Each source answers slightly different questions: systeminfo shows when the system booted; Win32_OperatingSystem gives a machine-readable timestamp you can script across many servers; Event Viewer gives the forensic trail (whether the reboot was planned and which process or user triggered it).

---

Method 1: Check Last Reboot with Command Prompt (fast, local)​

What to run​

• Open an elevated Command Prompt.
• Run:
• systeminfo | find "System Boot Time"

On English systems you'll see a human‑readable line like:

• System Boot Time: 2025-09-14, 11:26:07 AM

This is the quickest method when you’re at the console or using a simple remote command shell. The systeminfo tool prints a lot of diagnostics; piping and filtering isolates the boot line. (ss64.com)

Strengths​

• Extremely fast and easy to remember.
• No scripting or special permissions beyond admin‑level access to run systeminfo.
• Works on a broad range of Windows Server versions.

Important caveats and limitations​

• The displayed property name and format are localized. On non‑English systems the text search string must be adjusted for the local language. (ss64.com)
• On systems using Fast Startup (primarily client OSes but relevant in hybrid setups) or when hibernation/sleep are involved, systeminfo can show misleading results because fast startup actually writes hibernate‑style state instead of a full cold boot; this can make interpreted “uptime” drift or misrepresent previous boot events. Microsoft community threads and Q&A note these inconsistencies; therefore, treat systeminfo as a quick hint rather than an authoritative forensic record. (learn.microsoft.com)
• systeminfo only reports the most recent boot; it does not tell you why or who triggered a restart.

---

Method 2: Use PowerShell (scriptable, accurate, remote‑ready)​

The core command​

Open PowerShell (elevated) and run:

• (Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Or, for a human‑readable conversion and uptime calculation:

• $boot = Get-CimInstance -ClassName Win32_OperatingSystem
• $last = $boot.LastBootUpTime
• (Get-Date) - $last # returns a TimeSpan (uptime)

For older PowerShell versions or when using Get-WmiObject, convert WMI datetime using the .NET helper:
The Win32_OperatingSystem class exposes the LastBootUpTime property as a proper datetime value you can use in scripts and reports. Microsoft documentation and PowerShell guidance show exactly this pattern. (learn.microsoft.com)

Why use PowerShell​

• It is ideal for automation across many servers (Invoke-Command, PSSessions, or remote CIM calls).
• The value is machine‑readable and easy to convert to other formats or compare with Get-Date for uptime calculations.
• You can combine it with other checks (installed KBs, pending reboot flags, patching windows) in one script.

Examples (single line)​

• Show last boot timestamp:
• (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime
• Show uptime:
• (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Caveats and operational notes​

• Remote queries using CIM/WMI require WinRM or DCOM/CIM session access and appropriate firewall and credential configuration; ensure WinRM is enabled and trusted for cross‑server checks.
• If you rely on WMI/CIM remotely, verify that account permissions and firewall rules permit the queries; otherwise the commands will fail with access or RPC errors.
• Converting WMI datetime strings (if you use older cmdlets) requires Management.ManagementDateTimeConverter::ToDateTime or the object’s ConvertToDateTime method. The PowerShell team and official scripting blogs document this conversion. (devblogs.microsoft.com)

---

Method 3: Review Event Viewer Logs (forensics — who, why, and whether it was clean)​

The relevant logs and Event IDs​

Open Event Viewer (eventvwr.msc) and look under Windows Logs → System. Filter or search for these Event IDs:

• 1074 (User32) — A process or user initiated a restart or shutdown; the event text records the process name, the account, and the reason code. Use this to see who or what requested a restart. (learn.microsoft.com)
• 6005 / 6006 (EventLog source) — 6005: “The Event log service was started” (commonly used as a proxy for boot start). 6006 is the event log service stopping (shutdown). These are often used to infer boot and shutdown times when auditing. (learn.microsoft.com)
• 41 (Kernel‑Power) — System rebooted without cleanly shutting down: indicates a crash or power loss. Use in combination with 1074/6008 to identify unexpected reboots. (learn.microsoft.com)
• 6008 (EventLog) — Indicates the previous shutdown was unexpected.

How to use Event Viewer effectively​

• Open eventvwr.msc.
• Select Windows Logs → System.
• Right‑click → Filter Current Log → enter Event IDs: 1074, 6005, 6006, 41, 6008.
• Read the events in chronological order; 1074 typically tells you who or what (for planned restarts), while 41 and 6008 flag unclean or unexpected restarts. (learn.microsoft.com)

Strengths​

• Event Viewer gives the context — who initiated the restart, whether it was planned, and associated reason codes.
• Event logs are persistent and centrally useful for audits and post‑mortem analysis.
• Event IDs like 1074 explicitly include the process path (for example, WindowsUpdateAgent, RuntimeBroker, msiexec.exe), reason code, and (when provided) a user account or service name. (kb.eventtracker.com)

Caveats​

• Event logs can be noisy; other services (group policy, update clients, management tools) sometimes generate restart events. Correlate 1074 with other signals (WindowsUpdateClient events, installed KB entries, or scheduled tasks).
• If the Event Log service itself was stopped or logs were cleared, 6005/6006 timestamps might not be fully reliable; use a combination of Event IDs to deduce sequence. Microsoft’s troubleshooting guidance recommends checking several related Event IDs together. (learn.microsoft.com)
• On virtualized platforms, host‑level actions (live migration, host restarts) can affect guest perceptions; ensure you know whether you’re diagnosing the VM or the hypervisor host.

---

Advanced checks and automation patterns​

Scripted multi‑server check (PowerShell pattern)​

• Create a list of target servers.
• Use Invoke-Command or Invoke-CimMethod/Invoke-CimSession to query each machine:
• $servers = Get-Content servers.txt
• $servers | ForEach-Object {
  $os = Invoke-Command -ComputerName $_ -ScriptBlock { Get-CimInstance Win32OperatingSystem }
  [PSCustomObject]@{Computer=$; LastBoot=$os.LastBootUpTime; Uptime=(Get-Date) - $os.LastBootUpTime}
  }
• Export-Csv for reporting.

This pattern scales and produces consistent DateTime objects you can feed into dashboards or alerting rules. Use CIM sessions to reduce overhead in large fleets. (devblogs.microsoft.com)

Cross‑validation (recommended)​

When accuracy matters, cross‑validate:

• Compare PowerShell's LastBootUpTime vs systeminfo output.
• Cross‑check Event Viewer entries for a matching 6005 (or 1074) at or near that timestamp.
• If only one source is used you risk being misled by fast startup, suspended/resume behavior, or event log anomalies.

---

Common troubleshooting scenarios and what to look for​

Scenario: Unexpected reboots​

• Look for Event ID 41 (Kernel‑Power), which indicates an unclean reboot; then search for the nearest prior event 1001 (BugCheck) or for 6008 (previous shutdown was unexpected). Use 1074 to see if anything reported a planned restart around the same time. (learn.microsoft.com)

Scenario: System shows a recent boot but users claim it was running longer​

• Check whether Fast Startup or hibernation semantics caused systeminfo to report hibernation‑based boot time. Use CIM/Win32_OperatingSystem for a more consistent timestamp, and cross‑reference with event logs. (learn.microsoft.com)

Scenario: Audit wants “who restarted the server”​

• Use Event ID 1074; the event’s message explicitly names the process and the account that initiated the restart. If group policy or update agents are involved, the event text will usually identify them and give a reason code. (kb.eventtracker.com)

Scenario: Remote host refuses WMI/CIM queries​

• Validate WinRM is enabled (for PowerShell remoting/CIM over WSMan) and that firewall rules allow the traffic. If you must use legacy DCOM WMI (Get-WmiObject), ensure RPC ports and DCOM permissions are correct.

---

Security and audit considerations​

• Event logs are central to security investigations. Log retention and centralization (forward logs to a SIEM or centralized collector) prevent loss of evidence if a system is compromised. Correlate 1074 entries with account activity and scheduled tasks.
• The process path in Event ID 1074 is critical: if a non‑Microsoft process triggered restarts, treat it as suspicious and investigate the binary path, signer, and recent changes.
• When scripting queries across domains, ensure credentials follow the principle of least privilege and avoid embedding cleartext credentials in scripts.

---

Recommended daily / operational practice​

• For day‑to‑day checks: use PowerShell (Get‑CimInstance) in your monitoring scripts and dashboards — it is precise and easy to convert into uptime metrics. (devblogs.microsoft.com)
• For incident investigations: use Event Viewer filtering on IDs 1074, 6005, 6006, 41, 6008 to build the timeline. (learn.microsoft.com)
• Always cross‑validate critical findings across at least two sources (CIM + Event log) before drawing conclusions; the combination reduces false positives from fast startup, VM migrations, or service restarts. (ss64.com)

---

Quick reference — command cheatsheet​

• Command Prompt (fast, local):
• systeminfo | find "System Boot Time" — quick look (localized).
• PowerShell (scriptable, remote):
• (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
• (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime — uptime as TimeSpan.
• Management.ManagementDateTimeConverter::ToDateTime($wmiDT) — convert legacy WMI datetime. (blog.idera.com)
• Event Viewer (forensic):
• System log → filter Event IDs: 1074, 6005, 6006, 41, 6008. (learn.microsoft.com)

---

Final analysis — strengths, risks, and when to use each method​

• systeminfo
• Strengths: instant, zero scripting.
• Risks: localization, fast startup/hybernation drift, limited forensic detail.
• Best use: quick local checks and casual troubleshooting. (ss64.com)
• PowerShell + Win32_OperatingSystem (Get-CimInstance)
• Strengths: precise, scriptable, remote‑friendly, returns machine‑readable DateTime.
• Risks: requires remote access/WMI permissions and proper WinRM configuration for scale.
• Best use: reporting, automation across fleets, integration into monitoring/alerting systems. (devblogs.microsoft.com)
• Event Viewer (System log)
• Strengths: contextual and forensic — shows actor, reason codes, and whether reboots were clean or unexpected.
• Risks: logs can be cleared, rotated, or truncated; requires log analysis skills to correlate events correctly.
• Best use: incident response, audit trails, and answering “who/why” questions. (learn.microsoft.com)

If you adopt one practice for operations: automate PowerShell checks for all servers and keep Event Log parsing as a follow‑up in investigations. Cross‑validate any surprising result by checking at least one other source before acting.

---

Accurate boot‑time checks are a small but essential discipline for stable server operations. Use the right tool for the job: systeminfo for quick eyeballing, PowerShell/CIM for automation and fleet reporting, and Event Viewer for forensic context and security auditing. When in doubt, cross‑check and centralize logs — they are the single best defense against mystery reboots. (learn.microsoft.com)

---

Source: Windows Report How to Check Last Reboot in Windows Server [3 Ways]