Show CPU usage in the Mac menu bar
The fan spins up, the pointer starts to stutter, and the obvious question is which process is responsible. Opening Activity Monitor answers it, but only after the moment has passed. What most people actually want is a number that is already on screen when the slowdown starts, so the cause can be caught while it is still happening.
macOS gets surprisingly close to that without any installation, just not in the place people look. The live readout exists. It lives in the Dock. Whether that is good enough, and what changes if it is not, is the whole decision.
What macOS already gives you
Activity Monitor is in Applications, inside the Utilities folder, and it has three separate ways to show processor activity.
The main view is the CPU tab, which lists processes by load and shows three percentages along the bottom. Apple's guide describes them as System, the CPU used by macOS processes, User, the CPU used by your apps, and Idle, unused capacity. That breakdown matters more than the single combined number, and the reason is covered further down.
The second is a floating window. Choosing Window then CPU Usage opens a small window showing current processor activity, and Window then CPU History shows recent activity as a scrolling graph. These float above other windows and survive being left open all day.
The third is the one worth knowing about. Choosing View then Dock Icon, then picking the CPU option you want, replaces the Activity Monitor icon in the Dock with a live graph. This is the closest thing macOS has to an always visible processor readout, and it costs nothing.
Set it up once and it behaves well. Add Activity Monitor to login items so it starts with the Mac, and the Dock shows a live graph from the moment you log in.
Why the Dock is not the menu bar
For a real number of people the Dock graph is the end of the search, and installing anything else is wasted effort. For everyone else, three specific things push them toward the menu bar instead.
Dock visibility is the first. Anyone running the Dock hidden, which is the normal setup for people who care about screen space, has a readout that requires moving the pointer to the edge of the screen to see. That is the same problem as minimising a window.
Full screen is the second. Working in a full screen app puts the Dock away, and the graph goes with it. The menu bar, by contrast, can be configured to stay.
Resolution is the third. A Dock icon is a small square rendering a graph, and a graph in that space conveys shape rather than value. Reading whether load is at forty percent or seventy percent from it is guesswork. A menu bar item can show digits.
There is also a category difference that gets overlooked. The Dock graph shows processor load and nothing else. The moment you also want memory pressure, or network throughput, or a temperature, you are looking at a different class of tool, and every tool in that class puts its output in the menu bar.
The three shapes of menu bar system monitor
Tools in this category split cleanly by how they are funded, and that turns out to predict more about them than the feature list does.
| Tool | Cost | Minimum macOS | Notes |
|---|---|---|---|
| Stats | Free, MIT licence, open source | 12 | CPU, GPU, memory, disk, network, battery, sensors |
| iStat Menus 7 | One-time licence, upgrade price for version 6 owners | Published by the developer | Per-core usage and history graphs in the bar |
| iStatistica | $5.99, Mac App Store | 10.11 | Pro edition sold separately at $9.99 |
| Activity Bar | Free, Mac App Store | 13.0 | Menu bar system stats |
| MenuBar Stats | $4.99, Mac App Store | 11.0 | Last updated April 2023 |
Stats is the default recommendation in most threads and the reason is structural rather than sentimental. It is distributed under the MIT licence with source on GitHub, it covers CPU, GPU, memory, disk, network, battery, sensors, Bluetooth devices and a multi time zone clock, and it installs through Homebrew with a single command. Supported macOS is 12 and newer. Nothing is held back behind a payment, so the evaluation question is only whether the display suits you.
iStat Menus occupies the opposite corner. It is a paid one-time licence bought directly from the developer, with discounted upgrade pricing for owners of the previous version, and it is also included in the Setapp subscription at USD$9.99 per month alongside more than 250 other apps. Its CPU module shows current usage for individual cores plus history graphs directly in the menu bar. It also has a Combined mode that merges several of its items into a single menu bar item, choosing what appears in the bar and what appears in the dropdown, which is explicitly aimed at laptops where width is short.
The Mac App Store tier is where the small single purpose utilities sit. They are cheap, they are sandboxed, and update frequency varies widely, so checking the last updated date on the listing is a reasonable proxy for whether anyone is still maintaining it.
MenuMeters is still named in older guides and deserves an accurate note. The maintained fork is open source under GPL-2.0, and its own README lists support through Big Sur, having been restructured from a System Preferences pane into a standalone app starting with Catalina. Its maintainer points newer macOS users toward Stats and iGlance instead.
A percentage on its own is not a diagnosis
Adding the number to the menu bar solves visibility and then immediately raises a second problem, which is that the number is easy to misread.
Total CPU percentage on a modern Mac is reported against all cores. On a machine with a high core count, a single process pinning one core completely can show as a modest total figure while that one app is entirely unresponsive. The total looks calm and the experience is not.
The System and User split from Activity Monitor is the more useful signal, and a menu bar tool that shows the split, or shows per-core bars, is more diagnostic than one showing a single merged figure. Sustained high System time points at kernel work, drivers or filesystem activity. Sustained high User time points at an app. These lead to different next steps.
Efficiency and performance cores complicate the picture further on Apple silicon. Background work scheduled onto efficiency cores can push percentages up without affecting anything you are doing, which is working as designed rather than a problem to solve.
The practical rule that follows is short. Use the menu bar figure as a trigger, not as an answer. When it goes high and stays high, open Activity Monitor and sort by CPU to get the process name. The menu bar item's job is to tell you when to look, which is precisely the job the Dock icon was already doing, only better placed.
Make sure the bar is actually on screen when it matters
Moving the readout from the Dock to the menu bar only helps if the menu bar is visible at the moment the machine bogs down. That is not automatic, and the setting that governs it is easy to have turned on years ago and forgotten.
In System Settings under Menu Bar, the option to automatically hide and show the menu bar has four values, described by Apple as Always, which hides and shows the bar in every context, On Desktop Only, which hides it when not using an app in full screen, In Full Screen Only, which hides it while an app is full screen, and Never, which keeps the bar permanently visible. When the bar is hidden, moving the pointer to the top of the screen brings it back. On macOS Sonoma 14 and macOS Sequoia 15 these controls sit in Control Center settings rather than in a Menu Bar pane.
The interaction with a processor readout is direct. In Full Screen Only is the setting that quietly defeats the whole exercise, because rendering, exporting, compiling and video calls are exactly the workloads that both push the processor hard and tend to run full screen. The number is correct and invisible at the only moment it was wanted. Anyone monitoring load for those reasons should be on Never.
Always and On Desktop Only are worse still for this purpose, since they turn every check into a pointer movement, which is the Dock problem the menu bar was supposed to solve.
One display setting is worth a glance at the same time. The choice of whether to show your wallpaper behind the menu bar or to show the menu bar background affects legibility, and a monitor readout is thin digits and graph lines rather than a solid glyph, so it is among the first things to become unreadable against a detailed picture. If the figures are hard to parse at speed, changing that setting is quicker than changing tools.
What it costs in width, and in load
A system monitor is the most expensive kind of menu bar resident, because it rarely stays at one item. CPU goes in, then memory, then network, and each occupies real width because each is a graph or digits rather than a glyph.
This runs into a hard limit. When the menu bar has no room left, macOS hides items rather than wrapping them, and the choice of which items disappear is not yours. Dropbox describes this in its own support material, noting that macOS may hide icons when the bar is crowded and suggesting holding Command and dragging its icon toward the right side of the bar to make it less likely to be hidden. On a MacBook Pro the notch removes usable width before you start, so the ceiling arrives sooner.
Two things help. Combining modules into a single item, which iStat Menus offers directly, keeps several readings in one slot. And collapsing the items you rarely click behind a divider frees the width for the ones you are actually watching. If you go that route, the thing to check in the features list is whether a hidden item can be clicked without expanding the whole bar first, because a monitor you have to unfold is a monitor you stop reading.
The second cost is smaller but real. Every system monitor polls, and polling is itself work. Most of these tools expose a refresh interval. Moving from one second to two or three makes no practical difference to catching a runaway process and measurably reduces the monitor's own footprint, which matters on battery.
What to change first
Turn on View then Dock Icon in Activity Monitor and use it for a few days before installing anything, since it is free, immediate, and enough for most people. If the Dock is hidden or you work full screen, install Stats, enable the CPU module only, and set the refresh interval to two seconds. Add further modules only when you find yourself wanting one. If the bar runs out of room after that, a menu bar manager such as Koffret recovers the width by collapsing what you never click.
Frequently asked questions
Does macOS have a built in CPU meter for the menu bar?
Not for the menu bar. Activity Monitor can show a live processor graph in its Dock icon through View then Dock Icon, and it can open floating windows through Window then CPU Usage or Window then CPU History. Putting a processor readout in the menu bar itself requires a third party tool.
Is there a free option, or does this require paying?
Stats is free and open source under the MIT licence, covers CPU along with GPU, memory, disk, network, battery and sensors, and supports macOS 12 and newer. It installs from GitHub or through Homebrew. There are also free options on the Mac App Store, and paid tools mainly buy denser displays and combined items rather than data that is otherwise unavailable.
Why does the menu bar say CPU usage is low when my Mac feels slow?
The percentage is measured across all cores, so one process saturating a single core shows as a small fraction of the total on a machine with many cores. Check per-core bars if the tool offers them, and open Activity Monitor and sort by CPU to find the process. Slowness also comes from memory pressure or disk activity, neither of which appears in a processor figure.
Does running a system monitor slow the Mac down?
It uses some resources, since reading and drawing the values is continuous work. The effect is small at sensible settings and grows if you enable many modules at a one second refresh. Raising the interval to two or three seconds and turning off modules you do not read keeps the cost negligible, which matters most on battery.
Should I show CPU, memory, and network all at once?
Only if you act on all three. Each one takes real width, and when the bar fills up macOS starts hiding items without asking. Start with the single value that triggers your investigations, usually processor load, and add others when a specific question keeps going unanswered.