Display Uptime

What the macOS uptime reporter does

This Automox Worklet™ collects the current uptime and local time from each targeted macOS endpoint and writes a single readable line back to the Automox Activity Log. The Worklet does not change endpoint state. It is a fleet-wide reporter that turns the output of the native uptime command into a per-endpoint record you can scan in the console or pull through the Automox API.

The remediation script runs uptime, captures stdout, and inspects the string for the substring 'days'. When uptime is measured in days, the script prints local time followed by days, hours, and minutes since the last boot. When uptime is under 24 hours, it prints local time followed by hours and minutes. Both paths pipe through awk to extract the fields and through sed to strip the trailing commas the BSD uptime binary emits, so the line that reaches the Activity Log is consistent and easy to parse.

The evaluation script exits with code 1 unconditionally. That design is deliberate for a data-collection Worklet: every endpoint is flagged non-compliant on evaluation so that remediation runs on every endpoint and every endpoint reports its uptime line. There is no idempotent guard because there is no state to converge on, only a snapshot to capture.

Why audit macOS uptime across the fleet

Uptime on a Mac is a proxy for two operational questions Apple admins answer constantly. First: which endpoints have missed a reboot after a security update that requires one (kernel extensions, system extensions, recovery-installed updates, T2 firmware, full-disk encryption rekeys)? Second: which endpoints are restarting more often than expected? Frequent restarts can point to thermal events, kernel panics, MDM-triggered reboots, or end users power-cycling around a problem they have not filed a ticket for. The native uptime command answers both questions in one line. The hard part is collecting that line from every Mac without sshing into each one or trusting users to self-report.

Reading uptime by hand from one Mac at a time does not scale past a handful of endpoints, and end-user self-reporting is unreliable for security-sensitive reboots. Schedule this Worklet weekly against your macOS device group, then filter the Activity Log for the output line to build a reboot-cadence report across every Mac under Automox management. The same approach lets you confirm post-update reboots on fleets running kernel extension updates, T2 firmware refreshes, or full-disk encryption rekeys.

How macOS uptime reporting works

1. Evaluation phase: evaluation.sh runs exit 1 immediately. No checks are performed. This forces every targeted macOS endpoint into the remediation phase on every policy run, which is the correct shape for a data-collection Worklet where the goal is a fresh uptime snapshot at every evaluation.

2. Remediation phase: remediation.sh executes the BSD uptime command, captures stdout into the DISPLAY_UPTIME variable, and tests whether the string contains the substring 'days'. If it does, the script pipes uptime through awk to print 'Your local time is: $1. Your machine has been $2 $3 $4 $5.' using whitespace as the field separator, which surfaces fields like 'up 5 days 3:45'. If the substring is absent, the script prints the shorter form 'Your local time is: $1. Your machine has been $2 $3.', which surfaces fields like 'up 5:23'. In both branches, sed strips the trailing commas that the BSD uptime binary emits so the resulting line is whitespace-delimited and grep-friendly. The script returns the exit status of the final pipeline (normally 0), and Automox captures the stdout line and attaches it to the endpoint's run record.

macOS uptime reporting requirements

• macOS endpoint (Workstation or Server device type) with the Automox agent installed

• Default macOS toolchain: /usr/bin/uptime, /usr/bin/awk, /usr/bin/sed, and /bin/bash

• No additional privileges or third-party agents – uptime is unprivileged on macOS

• Compatible with FixNow (RunNow) for on-demand collection against a single device or device group

• Recommended scheduling cadence: weekly against the full macOS group, or paired with a reboot-required policy as a follow-up audit

Expected output in the Activity Log

Every targeted endpoint completes with the exit status of the final sed pipeline (normally 0) and a single line of stdout attached to its run record. A Mac that has been up for several days reports a line like 'Your local time is: 14:22. Your machine has been up 5 days 3:45.' A Mac that rebooted earlier the same day reports 'Your local time is: 09:11. Your machine has been up 5:23.' The line is whitespace-delimited and contains no commas, which makes it safe to grep, awk, or pipe into a CSV when you export the policy run.

To turn the raw lines into a reboot-cadence report, export the policy run results from the Automox console or pull them through the API, then sort or filter the output. Endpoints reporting more than 30 days of uptime are candidates for a forced reboot policy, because long-running Macs typically have pending kernel extension or system extension updates that require a restart to take effect. Endpoints reporting less than 1 hour repeatedly on consecutive runs are candidates for investigation under /Library/Logs/DiagnosticReports/ for kernel panics or under the unified log (log show --predicate 'eventMessage contains "shutdown"') for forced restarts.

Cross-reference the uptime line with sysctl kern.boottime if you need a machine-readable epoch timestamp instead of the human-readable string, or with last reboot when you need the reboot history rather than just the most recent boot. The Worklet is intentionally focused on the single-line Activity Log surface; richer reboot forensics belong in a companion Worklet that ships sysctl kern.boottime or last reboot output the same way.