A menu bar app is using too much CPU. How to find out which
· 6 min read
The fans come on. Nothing demanding is open. The battery is going down faster than the work you are doing would explain.
Something in the background is busy, and menu bar apps are a reasonable suspicion because they run continuously and are easy to forget. Identifying the culprit takes about a minute.
Find the process
Activity Monitor, in the CPU tab, sorted by the %CPU column, answers this. From the Terminal, more quickly:
ps -Ao %cpu,%mem,comm -r | head -12
-r sorts by CPU use, so the busiest processes are at the top. A sample from a Mac doing very little:
%CPU %MEM COMM
90.3 0.2 .../CoreSpotlight.framework/spotlightknowledged
33.5 2.7 /Users/you/.local/bin/claude
13.8 0.0 /bin/zsh
10.5 0.4 /System/Applications/Utilities/Terminal.app/...
2.9 0.1 .../EcosystemAnalytics.framework/Support/ecosystemanalyticsd
Note what the top entry is in that example: a Spotlight indexing process, not an app anyone launched. That is worth internalising, because system processes are frequently the answer and they are the ones people never suspect.
Steady load versus a spike
The single most useful distinction, and ps gives you a snapshot rather than a trend. Watch it over time:
top -o cpu -n 10
Press q to quit. Watch for thirty seconds.
A process that spikes and settles is doing a job: indexing, syncing, backing up. It will finish. A process sitting at a constant high figure for minutes is stuck, and that is what deserves attention.
Spotlight indexing after a large file copy, Photos analysing a library, Time Machine preparing a backup, and a cloud drive reconciling changes all look alarming and all end. Check whether something recently changed that would explain it before intervening.
What a background app should cost
For an app that watches something and does nothing else, the honest figure is close to zero, punctuated by brief activity when it does its work.
If a menu bar app sits at several percent continuously while idle, something is wrong with it. Common causes are polling on a tight loop instead of waiting for a notification, redrawing its icon far more often than the display refreshes, or retrying a network request that keeps failing.
The last one is worth checking separately, since it can also mean the app is repeatedly trying to reach a server that is down:
nettop -P -l 1 2>/dev/null | head -20
An app generating constant traffic while you are not using it is doing something you did not ask for.
Energy impact, which is not the same as CPU
Activity Monitor has an Energy tab, and its Energy Impact column is a better measure for battery than raw CPU percentage. It accounts for what a process does to the machine as a whole: waking the processor from idle, preventing sleep, using the graphics processor.
A process with modest CPU that wakes the machine constantly can cost more battery than one that uses more CPU in a single burst and then leaves the system alone. Sort by Energy Impact rather than CPU when battery is the concern.
To see what is actively preventing the Mac from sleeping:
pmset -g assertions
The output lists assertions such as PreventUserIdleDisplaySleep and PreventSystemSleep, along with which process is holding each. A menu bar app holding one of those permanently is a genuine problem, since it stops the machine resting at all.
Deciding what to do
Quit it and watch. The direct test. If the load goes with it, you have your answer.
Check for an update. Runaway CPU is often a bug that has been fixed.
Check what it is working on. Some apps are legitimately busy after a change: a first index, a large import, a sync backlog. Give it an hour before concluding anything.
Remove it. If an app costs measurable battery to do something you do not need, that is a fair reason to stop running it.
What Punchcard costs
Punchcard notices which application is in front, by application name only. That is a notification the system sends when the frontmost app changes, not a loop that polls, so there is nothing to do between changes and nothing running while you work in one app for an hour.
It has no networking code, so it cannot be stuck retrying a request. It asks for no macOS permissions, so it is not watching anything expensive. At the closing time it does its one piece of real work, printing a receipt of the day, which takes a couple of seconds.
The measured version of that question is in does a menu bar app drain your battery, and how automatic time tracking works covers what it is actually observing.
Questions
kernel_task is using enormous CPU. Is that a problem?
Usually the opposite. kernel_task consumes cycles deliberately to keep the processor cool when the machine is hot. It is a symptom of heat rather than a cause of it. Check what made the Mac hot.
WindowServer is high. That is the process drawing the screen. It rises with external displays, high resolutions, transparency and animation. Reducing transparency in Accessibility settings genuinely helps on older machines.
The app uses no CPU but the fans still run.
Check the Energy tab and pmset -g assertions. Something may be preventing sleep, or the load may be on the graphics processor rather than the main one.
Should I worry about a process I do not recognise?
Look at the path in the COMM column first. Anything under /System/ is part of macOS. Anything under /Users/ is something installed. Search the exact name before assuming the worst; most unfamiliar names are ordinary system components.