watch Command on Mac: The Loop Fix Lost 19s a Minute

Type watch kubectl get pods on a Mac and zsh answers zsh: command not found: watch, exit 127. macOS has never shipped watch. It comes from procps, a Linux package, and the BSD userland Apple uses has no equivalent. Two answers circulate: brew install watch, or a one-line while loop with clear and sleep. I tested both on this site's Mac mini. On a 2-second interval, the loop ran every 2.98 seconds, so it fell 19.5 seconds behind in one minute. It showed an empty screen 30% of the time, and Ctrl-C didn't stop it when the watched command caught the signal itself. Installed watch fixes two of those, and it brings its own traps.

The searches are real. Google autocomplete returns 33 completions for "watch command mac", mostly "watch command alternative in mac", "install watch command mac" and "watch command not found mac". On GitHub, the same moment shows up in bug reports. One minikube issue from a MacBook Air pastes watch -n1 kubectl get pods, the zsh error, then kubectl get pods typed by hand. A kubespray question has the same line with watch kubectl get all.

Setup for everything below: macOS 26.4.1, zsh 5.9 started with zsh -f, Apple's /bin/bash 3.2.57, and tmux 3.7c panes of 120 by 40, so I could sample the screen from a script. For the comparison I installed Homebrew's watch, which is procps-ng 4.0.7, and removed it afterward.

The loop everyone posts, and four tests

while true; do clear; kubectl get pods; sleep 2; done

I replaced kubectl with a script that writes a timestamp and takes about 0.86 seconds, ordinary for a command that talks to a server, and ran four checks on the loop and on watch: time between runs, how often the screen is empty, what Ctrl-C does, and whether shell aliases work.

Test	while + clear + sleep	brew watch 4.0.7
Mean time between runs, 2 s asked	2.975 s	2.978 s (-p: 2.112 s)
Screen samples that were empty	49 of 163 (30.1%)	0 of 163
Ctrl-C while the command catches SIGINT	keeps looping (zsh and bash)	exits, status 0
Alias ll as the command	works	sh: ll: command not found

Drift: 2 seconds became 2.98

The loop's interval starts when the command ends, so every pass costs the command's runtime plus the sleep. That accounts for 2.86 seconds. The other tenth came from sleep itself. In this session, /bin/sleep 2 returned after 2.13 to 2.15 seconds in three tries, and sleep 0.1 took up to 0.25. Starting a process costs 1 to 2 ms here, so the extra time is in the sleep, not the launch. I measured this from my scheduled, launchd-started session and didn't repeat it from Terminal.app, so your overshoot may be smaller.

Plain watch -n 2 drifted exactly like the loop, 2.978 seconds per run. That is by design. In the procps 4.0.7 source, the default mode records the time after the command finishes and waits a full interval from there. The help text says -p means "-n includes command running time". With -p, the clock starts when the command starts. That brought the period down to 2.112 seconds, but it's still not a fixed schedule. Each wait is computed from the latest start, so every timer overshoot carries forward, 3.24 seconds over 29 runs here.

For eyeballing pod status that doesn't matter. When you're timing something, like how long a deploy takes to go green, it does.

The empty screen is clear running first

The loop calls clear, then starts the command. Until the command prints, the terminal is blank. I sampled the pane every 20 ms for 30 seconds with a command that takes 0.7 seconds. 49 of 163 samples were empty, 30.1%. That matches 0.86 seconds of runtime out of a 2.98-second cycle. It reads as flicker when the command is fast and as a blank screen when it's slow. watch never blanked. It keeps the old output until the new one is ready, and it rewrites only the cells that changed. Refreshing the same 30-line listing once a second for 30 seconds, watch wrote 689 bytes to the terminal, mostly clock digits in its header. The loop wrote 47,398.

The fix in a shell loop is to capture the output first, then move the cursor home and overwrite instead of clearing. That loop also scored 0 empty samples. It still redraws every byte, but you don't see a gap.

Ctrl-C can't stop the loop

This one surprised me. I replaced the command with a small Python script that catches KeyboardInterrupt and exits 1, which is what many monitoring scripts do. I sent Ctrl-C into a running loop and checked whether it kept writing timestamps.

loop child           zsh -f -i        bash 3.2 -i
sleep 1.5            stopped          stopped
python (exit 1)      STILL RUNNING    STILL RUNNING
same, in ( ... )     stopped          STILL RUNNING
watch -n 0.5         exits, status 0

An interactive shell runs the loop's commands in their own process group, so Ctrl-C goes to the Python script, not the shell. The shell sees a child that exited 1 and moves to the next pass. A trap 'return 130' INT in a function didn't help in either shell for the same reason: the shell never received the signal. Wrapping the loop in a subshell, ( while ...; done ), puts the subshell in the foreground group too. zsh then stopped. Apple's bash 3.2 kept going, even with a trap 'exit 130' INT inside the subshell. The current bash manual says bash assumes a child that didn't die from SIGINT handled it on purpose, but still runs a SIGINT trap. 3.2.57 did not run that trap in my test. In the everyday version of the loop there is a sleep between runs, and a Ctrl-C that lands during the sleep did stop it in both shells. So if one press doesn't work, press again during the pause.

What brew install watch gives you, and what it doesn't

brew install watch is the common route. The Homebrew formula page counted 86,420 installs in the past year when I checked. The alternatives are far behind: entr 8,225, viddy 2,844, hwatch 2,104. Installing it fixes the blank screen and Ctrl-C. Four things still caught me:

• Aliases and shell functions don't exist inside it. watch runs the command with sh -c. watch ll printed sh: ll: command not found, with (127) in the header's exit-status slot. Type the real command.
• Quote pipelines. watch -n 1 date | head -3 pipes watch's screen output into head. The terminal stayed blank, the output file had 0 bytes after 4 seconds, and it hung until Ctrl-C. Write watch -n 1 'date | head -3'. If you script around watch, check every stage of the pipeline, as in bash pipe exit codes.
• Colors need -c. With CLICOLOR_FORCE=1 watch ls -G, the screen showed raw codes like [34mbin[39;49m[0m. watch -c rendered them.
• Exit flags report different things. watch -e exits with the failing command's status, 1 in my test. watch -g, which exits when the output changes, returned 0, so a script can't tell from the status alone why it stopped.

Plain watch -n 2 still drifts by the command's runtime. Add -p if the timing matters. The minimum interval is 0.1 seconds. Smaller values are raised to that.

A watch for a stock Mac

On a machine where you can't install anything, this zsh function fixes the four problems above. It schedules runs on a fixed clock with $EPOCHREALTIME, captures output before drawing, runs the command through eval so aliases work, and runs the loop in a subshell so Ctrl-C stops it in zsh, which is the default shell on current macOS.

# watch for a stock Mac: no drift, no blank frame, Ctrl-C always stops it
wat() {
  emulate -L zsh
  zmodload zsh/datetime
  local n=2
  if [[ $1 == -n ]]; then n=$2; shift 2; fi
  local -F next=$EPOCHREALTIME
  local out eol=$'\033[K\n'
  (
    trap 'exit 130' INT
    while true; do
      out=$(eval "$*" 2>&1)
      printf '\033[H%s\033[K\n%s\033[K\n\033[J' "Every ${n}s: $*" "${out//$'\n'/$eol}"
      (( next += n ))
      (( next > EPOCHREALTIME )) && sleep $(( next - EPOCHREALTIME ))
    done
  )
}

With the same harness, wat -n 2 averaged 2.002 seconds between runs over 33 runs and ended 0.06 seconds off the 2-second grid. No screen sample out of 308 was empty. alias ll='ls -l'; wat -n 1 ll /usr/local printed the listing, and Ctrl-C stopped the loop even while the Python script that catches it was running. The \033[K and \033[J codes erase leftovers, so output that shrinks from six lines to one doesn't leave stale lines behind. I checked that too.

It's not a full replacement. It doesn't highlight differences, it has no -e or -g, and output taller than the window scrolls the header away, where watch cuts at the screen edge. Pipe into head inside the quotes if that bothers you. If a run takes longer than the interval, the schedule falls behind and the next runs start back to back until it catches up. It needs zsh. Under bash 3.2, the subshell trick didn't stop the loop, so on bash I'd install watch.

watch is one of several Linux commands a Mac doesn't have. My earlier sweep found timeout and 18 other coreutils commands missing on macOS, and the substitute for nproc on Mac has its own trap. If you watch long jobs in a terminal multiplexer, my notes on running Claude Code in tmux cover the settings I use for those sessions.

How this was measured: every number comes from one session on 2026-10-01 on this site's Mac mini M4 (macOS 26.4.1, build 25E253), driven by scripts in detached tmux 3.7c panes. Timing used perl Time::HiRes timestamps written by the watched command itself. Empty-screen and byte counts came from tmux capture-pane sampled every 20 ms and tmux pipe-pane. Ctrl-C was sent with tmux send-keys, and a loop counted as running if it logged new timestamps in the following 5 seconds. Homebrew watch was procps-ng 4.0.7, installed for the test and removed afterward. Its timing behavior is quoted from that version's source. Install counts are from the Homebrew formula API that day. The two GitHub issues were read in full via the GitHub API. The scripts are kept with my research notes.