How to See Mac Uptime (and Why It Matters for Performance)

You’re trying to figure out why your Mac feels slow. Activity Monitor isn’t showing anything dramatic. Disk space is fine. RAM looks normal. The thing nobody mentions: how long since you last rebooted?

uptime is a tiny command — one of the oldest in Unix — that answers this question. It also turns out to be one of the more useful diagnostic numbers on a Mac, because macOS accumulates state in ways that gradually slow it down. Long uptime correlates with sluggishness more often than people admit.

The basic command

uptime

Output:

14:32  up 23 days, 4:17, 1 user, load averages: 1.52 1.48 1.38

Five things on that line:

1. Current time (14:32).
2. Days and hours since the last boot (up 23 days, 4:17).
3. Number of logged-in users.
4. Load averages over the last 1, 5, and 15 minutes.

The uptime portion is what we care about for this guide. 23 days is a lot. For most personal Macs, anything over a week is worth a reboot.

Last reboot reason

To see the actual boot history:

last reboot

That dumps a list:

reboot    ~                         Tue Apr 22 09:45
reboot    ~                         Mon Apr  7 21:11
reboot    ~                         Tue Mar 26 16:23
...

Each line is a boot event, with timestamp. Going back further than current week sometimes requires:

last reboot | head -20

This is reading /var/log/wtmp (or the modern equivalent) — login/logout records. Useful for “when was the last time this Mac was unstable enough that I rebooted?”

For the related “when did I last shut down”:

last shutdown

Same format, different event type.

Boot time as a Unix timestamp

For scripting, you might want the boot time directly:

sysctl -n kern.boottime

Output:

{ sec = 1714003200, usec = 0 } Sun Apr 22 09:00:00 2026

Just the seconds:

sysctl -n kern.boottime | awk -F'[, =]+' '{print $4}'

That gives you a Unix timestamp you can do math on.

A clean “uptime in seconds”:

echo $(( $(date +%s) - $(sysctl -n kern.boottime | awk -F'[, =]+' '{print $4}') ))

Useful in monitoring scripts that want to alert at a threshold.

Why long uptime matters on macOS

In an ideal world, uptime would be irrelevant — a Mac running for 100 days would feel identical to one that just booted. In practice, that’s not how it works. Several things accumulate:

Memory pressure. Many apps leak memory over time. Even if the leak is slow, after a week of uptime you might have gigabytes of memory in inactive states that the system isn’t fully reclaiming.

File descriptor exhaustion. Some daemons leak file handles. Eventually you hit the per-process limit and things start failing in weird ways.

Stuck launchd jobs. A job that crashed and got stuck in a respawn loop can chew CPU silently for days.

Cache corruption. Icon cache, font cache, Quick Look cache — all can develop subtle issues that only resolve on reboot.

Network state. WiFi drivers can get into degraded states that look like “slow internet.” Reboot fixes it.

APFS state. Filesystem caches in memory can get fragmented. The OS handles it gracefully but never as well as a fresh boot.

A reboot resets all of this. Empirically, a Mac that’s been up for a month feels different from a Mac that was rebooted yesterday — even with the same apps, same workload, same configuration. It’s not magic; it’s just the OS getting back to a known-good state.

What “load average” tells you

The three numbers at the end of uptime are 1, 5, and 15-minute load averages. They represent the average number of processes that wanted to run, including those waiting on I/O.

On Apple Silicon Macs with 8+ cores, a load average under your core count means “the CPU is keeping up.” Above that, processes are queuing.

Rough interpretations on a typical Mac:

• 0.0–1.0: idle to light load.
• 1.0–3.0: normal use, browser plus IDE.
• 3.0–8.0: heavy load — compiling, video export.
• 8.0+: something’s running hot.

The trend matters more than the absolute number. If the 1-minute average is 8 and the 15-minute is 1, you just kicked off something heavy. If both are 8, you’ve been heavy for a while.

The load average doesn’t tell you what is running hot — for that, top -o cpu or htop.

Power users use Sweep tooEven when you know the Terminal commands, Sweep is faster and harder to mess up. Get Sweep free →

A handy uptime alias

Drop this in ~/.zshrc:

alias up='uptime; echo "Boot: $(sysctl -n kern.boottime | awk -F\" \" \"{print \$5,\$6,\$7,\$8}\")"'

Now up gives you uptime plus the actual date and time of the last boot, in one shot.

Uptime for scripting decisions

Sometimes you want to skip work if the system was just rebooted (give services time to settle):

UPTIME_SEC=$(( $(date +%s) - $(sysctl -n kern.boottime | awk -F'[, =]+' '{print $4}') ))
if (( UPTIME_SEC < 600 )); then
  echo "System just booted; sleeping for stability"
  sleep 300
fi

Or the opposite — alert when uptime exceeds a threshold:

THRESHOLD=$((30 * 24 * 3600))  # 30 days
if (( UPTIME_SEC > THRESHOLD )); then
  osascript -e 'display notification "Time to reboot — uptime exceeded 30 days" with title "Mac maintenance"'
fi

Wrap that in a launchd job and you’ve got automated reboot reminders.

Sleep doesn’t reset uptime

A common misconception: closing your MacBook’s lid resets uptime. It doesn’t. Sleep is just suspending the CPU; the kernel’s “boot time” doesn’t change. So a Mac you’ve been using for a month, sleeping every night, has a month of uptime — not a day.

To check: sleep your Mac, wait, wake it, run uptime. The number keeps climbing.

The only thing that resets uptime is shutdown, reboot, or a kernel panic (which is technically also a reboot). Sleep, hibernate, and “fast boot” all preserve uptime.

”Reboot” vs “Shut Down” vs “Restart”

In the Apple menu:

• Restart: standard reboot. Resets uptime. Fast on Apple Silicon.
• Shut Down: powers off. Next boot cold-starts. Resets uptime.
• Sleep: doesn’t reset uptime; just suspends.

Some old advice says “shut down once a week is good for the SSD.” That’s outdated — modern SSDs are fine being on indefinitely. There’s no longevity difference between restarting and shutting down.

For maintenance purposes, restart is enough.

Recovery boots

If you boot into recovery mode (hold the power button on Apple Silicon, or Cmd+R on Intel), that creates a separate “boot” event. After exiting recovery and booting normally, uptime is reset. So if you went into recovery to run fsck or reinstall macOS, that counts as a reboot for uptime purposes.

Checking last reboot’s cause

Sometimes you want to know whether the last reboot was clean (you triggered it) or a panic (the kernel died). The system log keeps this:

log show --predicate 'eventMessage contains "boot"' --last 30d --style compact | head -20

A clean shutdown and reboot leaves messages like “Shutdown initiated by user.” A kernel panic leaves a panic log in /Library/Logs/DiagnosticReports/:

ls /Library/Logs/DiagnosticReports/Kernel*

If there are recent kernel panic reports, that’s what caused your unexpected reboot. Open one in Console.app to see the stack trace.

Skip the Terminal stackSweep does the same cleanup with a UI and a preview before anything is removed. Download Sweep free →

A reboot routine that doesn’t suck

The reason people don’t reboot is the disruption — closed terminals, lost browser tabs, half-typed messages. Some habits help:

1. Use tmux for shells you want to keep. Just tmux attach after reboot. Won’t survive the reboot itself, but keeps your in-session organization.
2. Use a session manager for browser tabs. Both Safari and Chrome can reopen the previous session at launch — turn it on.
3. Save and quit. A reboot loop should be a habit: Cmd+S everywhere, quit foreground apps, then reboot. Background apps don’t matter.
4. Schedule it. Friday afternoon before you wrap up. By Monday, the Mac is fresh.

If a weekly reboot feels excessive, monthly is still better than three months. The point isn’t dogma; it’s not letting uptime accumulate to the point where weird stuff starts happening.

When the system says “your Mac restarted because of a problem”

That dialog appears after a kernel panic. macOS records the cause in /Library/Logs/DiagnosticReports/Kernel-<date>.panic. The first few lines tell you which subsystem panicked — often a kernel extension or a driver.

Common causes on modern Macs:

• A flaky USB-C dock or hub.
• An external GPU.
• A third-party kernel extension that’s not signed for your macOS version.
• Rare: failing RAM (mostly a concern for older Intel Macs with replaceable RAM; Apple Silicon’s unified memory is soldered and rarely fails).

If panics are frequent, Apple’s recommendation is to disconnect peripherals one at a time to find the trigger.

When uptime is the only diagnostic you need

A pattern I see often: a developer’s Mac is “slow,” they spend an hour in Activity Monitor, run top, check Disk Utility, look at logs. Eventually they reboot in frustration. The Mac is suddenly fast.

Reboot first. Diagnose later. It’s not satisfying advice for a power user, but it’s right more often than not. The few cases where uptime isn’t the answer are easy to identify after the reboot — the slowness comes back within a day, and now you can rule out “OS state weirdness” and look at actual configuration.

A tiny script for “should I reboot?”

#!/bin/bash
DAYS=$(uptime | awk '{print $4}')
case "$DAYS" in
  ''|*[!0-9]*)
    echo "Uptime less than a day — fine."
    ;;
  *)
    if (( DAYS > 14 )); then
      echo "Up $DAYS days. Consider rebooting."
    else
      echo "Up $DAYS days. Probably OK."
    fi
    ;;
esac

Drop it in ~/bin/should-i-reboot and run it during routine check-ins.

There’s a GUI for thatSweep wraps the Terminal cleanup in a UI you don’t have to memorize. Try Sweep free →

Bottom line

uptime is two-second diagnostic that tells you something Activity Monitor doesn’t. If your Mac has been up for two weeks and feels off, the answer is almost always “restart it.” Memory leaks, accumulated kernel state, and quirky daemons resolve themselves on a fresh boot in a way that no amount of purge or “clear cache” can match.