powermetrics must be invoked as the superuser

powermetrics -n 1 -i 200

powermetrics must be invoked as the superuser

The fix is sudo:

sudo powermetrics -n 1 -i 1000 --samplers cpu_power

There is no unprivileged mode and no flag combination that avoids this. What is worth knowing is which of the things people run powermetrics for can be obtained without root, because for several of them the answer is yes.

0

Why root is required

powermetrics does not read a file or call a public API. It attaches to kernel-level performance counters and to the power management subsystem, reading per-core idle residency, frequency residency, package power rails and interrupt attribution.

Those counters expose activity across every process on the machine. An unprivileged process reading them could infer a great deal about what other users are doing from timing and frequency patterns alone. Restricting them to root is the same reasoning that keeps dtrace and much of ktrace privileged.

What you can get without root

Most people running this command want one of four things. Three of them are available unprivileged.

Thermal pressure

pmset -g therm

Reports whether the system is under thermal pressure and whether CPU speed limits have been applied. This is usually the actual question behind “is my Mac throttling”, and it needs no privileges.

Battery draw right now

ioreg -rn AppleSmartBattery | grep -oE '"(InstantAmperage|Amperage|Voltage)" = -?[0-9]+'

Amperage in milliamps, negative while discharging, and voltage in millivolts. Multiply the two and divide by a million for watts. Not as precise as the package power rails, and it measures the whole system rather than the CPU alone, but it is a real measurement of real power draw and it updates continuously.

Core topology

sysctl -a | grep -E "hw\.(nperflevels|physicalcpu|logicalcpu|perflevel[01]\.)"

Core counts, cache sizes and cluster arrangement for both performance levels. Static rather than live, so it tells you what the chip is rather than what it is doing.

Per-core residency

No unprivileged equivalent. If you need to know which cores were busy and at what frequency, sudo powermetrics is the only route on macOS. This is the one genuine gap.

Running it usefully

Once you are using sudo, the defaults are noisier than they need to be. Two flags matter.

sudo powermetrics --samplers cpu_power -i 1000 -n 5

--samplers restricts output to what you asked for. Without it, powermetrics prints every sampler it has, which on Apple Silicon is several screens per interval. Useful samplers are cpu_power, gpu_power, thermal, battery and interrupts.

-i sets the interval in milliseconds. The 200 ms in the original failing command is too short for most purposes: sampling itself wakes the CPU, so at short intervals the tool measurably contributes to what it is measuring. At 1000 ms or above the overhead stays well under the signal.

-n limits the number of samples so the command exits on its own instead of running until interrupted.

A note on making it permanent

It is possible to add a sudoers entry allowing powermetrics without a password prompt:

your-username ALL=(root) NOPASSWD: /usr/bin/powermetrics

This is convenient for repeated measurement sessions and it is a real widening of your attack surface: any process running as you can then read kernel counters without prompting. On a single-user machine you control, that may be an acceptable trade. On a work machine or anything shared, typing the password is cheaper than the exposure.

The short version

sudo powermetrics --samplers cpu_power -i 1000 -n 5. Before reaching for it, check whether pmset -g therm or the ioreg battery values answer your question, because both of those run as you and neither requires thinking about sudoers.

Reading the output you get

The default output is dense enough that most people run it once and give up. Three sections are worth knowing.

The CPU section reports frequency and idle residency per core cluster rather than per core:

sudo powermetrics --samplers cpu_power -i 1000 -n 3

Residency is the fraction of the interval each cluster spent at each available frequency, plus the fraction spent idle. A cluster showing 90 percent idle residency during what you thought was a heavy workload usually means the work is not CPU-bound at all, and that is a more useful finding than a frequency number.

The package power figures are given in milliwatts and are broken out by domain: CPU, GPU, and often ANE for the neural engine. These are the only software-readable power figures on the machine that separate those domains, which is what makes powermetrics irreplaceable despite the privilege requirement.

The interrupt section attributes wakeups to processes. A laptop with poor battery life and no obvious culprit in Activity Monitor frequently has one process generating tens of thousands of timer wakeups, and this is where that shows up:

sudo powermetrics --samplers interrupts -i 5000 -n 2

Sampling changes what it samples

This deserves more emphasis than it usually gets. Taking a sample requires waking the CPU, so powermetrics contributes to the activity it reports. At the 200 ms interval in the failing command at the top of this article, the tool is waking the machine five times a second, which is enough to visibly raise idle power on a laptop doing nothing.

For anything power-related, 1000 ms is a reasonable floor and 5000 ms is better. The measurement you want is usually an average over a period, not a high-resolution trace, and a longer interval both reduces the distortion and produces a more stable number.

If you genuinely need fine resolution, take it for a short window and state that the tool’s own overhead is inside the result:

sudo powermetrics --samplers cpu_power -i 200 -n 25

Twenty-five samples at 200 ms is five seconds of data, which is enough to catch a transient without leaving the machine perturbed for long.

Logging without watching

For anything longer than a couple of minutes, write to a file and analyse afterwards:

sudo powermetrics --samplers cpu_power,gpu_power -i 5000 -n 720 \
  > ~/power-log.txt 2>&1 &

That is an hour of data at five-second resolution. Because the output is plain text rather than structured, extracting a single field is a grep away:

grep "CPU Power" ~/power-log.txt | awk '{print $3}' | \
  awk '{s+=$1; n++} END {printf "mean CPU power: %.0f mW over %d samples\n", s/n, n}'

Running the whole thing under sudo for an hour means leaving a privileged process alive, which is worth being deliberate about rather than habitual.

What to reach for instead, most of the time

The honest summary of this article is that powermetrics is the right tool considerably less often than it is reached for. If the question is whether the machine is thermally limited, pmset -g therm answers it without privileges. If the question is which application is draining the battery, Activity Monitor’s Energy tab answers it with attribution that powermetrics does not provide. If the question is how much power the machine is drawing right now, the battery’s own amperage and voltage give a real figure.

powermetrics is for the narrower question of where inside the chip the power went, and how each core cluster spent its time. That question is worth asking less often than it seems, and when it is worth asking, nothing else on the machine can answer it.

The short version

sudo powermetrics --samplers cpu_power -i 1000 -n 5.

Before reaching for it, check whether pmset -g therm or the ioreg battery values already answer your question, because both run as you. Root is required only for per-core residency and package power, and those are needed considerably less often than they are reached for.

A last note on sampling honesty

Any figure taken from powermetrics should be quoted with the interval it was sampled at, because the tool’s own wakeups are inside the measurement. A power figure sampled at 200 ms and one sampled at 5000 ms on an otherwise idle machine are not the same measurement, and the first is measurably higher because of the sampling itself. Stating the interval alongside the result costs one clause and makes the number reproducible.