How to Check Server Uptime on Linux and Windows

To check time since boot, run uptime on Linux or (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime in PowerShell. To monitor whether a server’s application is available, run repeated checks from another host. These answer different questions: a machine can stay powered on while its API is down.

This guide covers both the local commands and an ongoing service monitoring setup.

Check Uptime on Linux

The uptime Command

The simplest way:

$ uptime
 14:23:45 up 127 days, 3:42, 2 users, load average: 0.15, 0.10, 0.08

This tells you: current time, how long the system has been running, logged-in users, and load averages for 1, 5, and 15 minutes.

Using /proc/uptime

For a machine-readable format:

$ cat /proc/uptime
10987654.32 21234567.89

The first number is uptime in seconds. The second is total idle time across all CPUs. To convert to days:

$ awk '{print int($1/86400)" days"}' /proc/uptime
127 days

Using who -b

Shows the last boot time:

$ who -b
         system boot  2025-10-30 10:41

Using systemd-analyze

On systemd-based systems, get detailed boot timing:

$ systemd-analyze
Startup finished in 1.234s (kernel) + 3.456s (initrd) + 12.789s (userspace) = 17.479s

Using last reboot

See a history of all reboots:

$ last reboot
reboot   system boot  5.15.0-89-generic  Wed Oct 30 10:41   still running
reboot   system boot  5.15.0-86-generic  Mon Sep 15 08:22 - 10:41 (45+02:19)

Check Uptime on Windows

Using systeminfo

Open Command Prompt or PowerShell:

systeminfo | find "System Boot Time"

Output:

System Boot Time:          10/30/2025, 10:41:23 AM

Using PowerShell

More precise with PowerShell:

(Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Output:

Days              : 127
Hours             : 3
Minutes           : 42
Seconds           : 15

Or as a one-liner for just the uptime:

$os = Get-CimInstance Win32_OperatingSystem
"Uptime: $((Get-Date) - $os.LastBootUpTime)"

Using Task Manager

For a quick visual check:

1. Open Task Manager (Ctrl+Shift+Esc)
2. Go to the Performance tab
3. Look at Up time in the bottom-left of the CPU section

Using net statistics

net statistics server

The “Statistics since…” line shows when the Server service started, which typically aligns with boot time.

Remote Server Uptime Check

Via SSH (Linux)

ssh user@server "uptime"

Via SNMP

For monitoring systems that support SNMP:

snmpget -v2c -c public server.example.com 1.3.6.1.2.1.1.3.0

Returns sysUpTime in hundredths of a second since the SNMP agent started.

Via Monitoring Tools

The most reliable way to check uptime over time is external monitoring. Server-side commands only show time since last reboot, not actual availability from a user’s perspective. A server can be “up” but unreachable due to network issues, firewall changes, or application crashes.

External uptime monitoring tools measure reachability from the observer’s location. That is useful evidence about one network path, not a measurement of every user’s experience.

Automating Uptime Checks

Cron Job (Linux)

Log uptime every hour:

# Add to crontab -e
0 * * * * echo "$(date): $(uptime)" >> /var/log/uptime.log

Scheduled Task (Windows)

Create a PowerShell script that logs uptime:

$uptime = (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
"$(Get-Date): Uptime $($uptime.Days)d $($uptime.Hours)h" | Out-File -Append C:\logs\uptime.log

Schedule it with Task Scheduler to run hourly.

Server Uptime vs Service Uptime

Important distinction: server uptime (time since last reboot) is not the same as service uptime (time your application is accessible to users).

Your server can be up for 365 days while your web application crashes multiple times a week. The server uptime command won’t show you those application-level outages.

For true availability monitoring, you need external checks that test your application’s actual endpoints, not just whether the OS is running. Use the uptime calculator to understand what different availability levels mean in practice.

Monitor server availability over time

Choose a check that matches the service you need to protect:

Warden supports these checks, plus DNS and Docker container checks. Run it on a different host from the service when you need to detect that service’s host failing. A single Warden instance still observes from one location; it has no managed global probe network.

1. Install Warden with a persistent volume.
2. Add your service, choose the check type and start with a 60-second interval.
3. Configure a notification channel and confirm a test message arrives.
4. Use a disposable test endpoint to verify down and recovered events before relying on alerts.

Follow the API uptime and response-time walkthrough for the HTTP settings. Keep operating-system boot history for reboot investigations and service-check history for availability investigations.

Does Warden collect Linux uptime or Windows boot time?

No. Its ping, TCP and HTTP checks measure reachability or application responses. The commands above collect time since boot. Combining both helps distinguish a reboot from an application or network failure without confusing the two measurements.

From a boot-time check to ongoing service monitoring

A server can have weeks of uptime while its API is failing. Keep the commands above for reboot investigations; use an external HTTP check to answer whether a service is available from another host.

Warden by Project Helena checks service availability and response time, confirms failures and keeps incident evidence. Set up one monitor and verify an alert, or choose managed Warden for $49/month if you want us to operate the monitoring instance. Hosted checks need network access to the target; for private services, discuss connectivity first or self-host inside the network.

Related tools:

• Uptime Calculator — Convert between uptime percentages and downtime
• Error Budget Calculator — Track your allowed downtime budget

Put one endpoint under observation

Set up your first Warden monitor, confirm successful checks, then verify a failure and recovery with a disposable endpoint. Keep server boot time, synthetic availability and application health as separate measurements.