Open-source project
Zesty0wl/mac-performance-monitor avatar
Zesty0wl/mac-performance-monitor

Mac Performance Monitor: a menu bar recorder for diagnosing Mac slowdowns

A diagnostic performance logging utility for macOS: logs CPU, memory, GPU, network, and battery from the menu bar to help detect and diagnose performance issues. Free, open source, no telemetry.

838 stars38 forksSwiftMIT

At a glance

What is it?
A Swift 6 menu bar tool that logs CPU, memory, GPU, network, disk, battery and sensor readings so you can return to the moment a spike began. It is free, MIT licensed and keeps samples on your Mac, but it needs macOS 15 and Apple silicon.
Who is it for?
Adopt it if you are on macOS 15 or later with an Apple silicon Mac and you want a local, MIT-licensed record of what the machine was doing when it slowed down, installed either from the Homebrew cask mac-performance-monitor or the notarized MacPerformanceMonitor.pkg. Skip it on Intel Macs and on macOS 14 or earlier, where the README's stated requirements rule it out, and skip it if you want a live readout only, since Activity Monitor already covers that without a recorder.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Swift, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What Mac Performance Monitor is for

The problem is timing. When a Mac stutters, Activity Monitor shows the present tense: by the time you open it, the spike has passed and the process that caused it may have exited. Mac Performance Monitor is built around the opposite idea. It records samples continuously in the background so you can go back to the moment a slowdown or spike began, then compare CPU, memory, GPU, network, disk, battery and sensor readings with the processes behind them.

The audience is narrow and specific. The README requires macOS 15 or later and an Apple silicon (arm64) Mac, so Intel machines are not supported. Within that group, the tool suits people who already know how to read a process table and want evidence rather than a cleanup wizard. The menu bar readout and the history recorder have separate switches, so a live readout and a quiet background recorder are two different modes of the same app, not one bundled behaviour. The README states there is no usage telemetry and that recorded samples stay on the Mac.

How the recorder and Explorer fit together

Two pieces carry the design. The first is the recorder, which writes samples to a local database. The second is Explorer, which replaced the Analytics start screen in version 2.0 and acts as a workspace over both live and recorded data. In Explorer you pick a time, add the signals you need, and compare up to eight processes, including ones that have already exited. Hovering moves a shared cursor across charts, clicking pins a time, and Command plus scroll zooms around the pointer while ordinary scrolling moves the page.

Two constraints in the README are worth internalising. Older data keeps its retained resolution, and zooming does not invent detail, so the recorder's sampling choices set a ceiling on what you can later inspect. Separately, hardware inventory is a current snapshot rather than history, so do not treat it as a timeline. Process detail and Explorer can also show earlier, non-overlapping runs of the same program with gaps at restarts, which is what makes an exited process still investigable.

Version 2.1 reworked alerts around change rather than absolute levels. High swap usage alone is not a reason to warn you; the rules look for continued growth or paging strain, and they can report further worsening without first waiting for usage to fall below an old fixed limit. Process-growth checks reject stale readings and growth that has settled, and modest findings stay as quiet observations rather than a diagnosis of a memory leak. A separate fast-growth check catches runaway use without waiting 20 minutes. Clicking the menu bar alert badge shows active issues and their evidence; ordinary alerts can be snoozed for an hour or opened in Explorer at the relevant time, and only critical notices request sound.

Installing from the Homebrew cask or the notarized package

The README points to two installation routes: a Homebrew cask named mac-performance-monitor, and a MacPerformanceMonitor.pkg attached to GitHub releases, described as notarized by Apple. The cask is the route the README surfaces in its badge row, and the badge links to the cask page on formulae.brew.sh. The README does not print an install command itself, so the identifier above is the only part of the install you can copy from the repository material.

After installing, the app appears in Applications. The README does not document a first-run wizard, so the first real use is the one it does describe: enable the menu bar readout, and decide separately whether the history recorder should run. The README does not document command line flags for the app itself, so nothing beyond launching it from Applications should be assumed. Once it is running, right-click a row in the process table and choose Usage Timeline for sampled running history. That is the shortest path from install to a real answer about a process.

Where the recording model breaks down

The recorder is only as good as what it captured. New database fields added in 2.x preserve detail from new samples, and the README is explicit that they cannot restore missing older readings. If you upgrade and then try to investigate a slowdown from before the upgrade, expect gaps rather than backfilled data. The same logic applies to downgrades: the README says to back up the app's data before testing one.

The optional Apple app and media activity view has its own friction. It requires Full Disk Access and a per-window opt-in, and the app keeps those activity records in memory only. The README also describes the device and foreground status it shows as unverified. So this is a feature with a permission cost, a scope limit and a confidence caveat, and it is reasonable to leave it off.

Finally, the battery forecast is not a promise. Runtime uses macOS estimates or recent steady use, and the dashed forecast is kept separate from real charge data. It assumes the same workload. Anyone reading it as a fixed prediction of remaining battery life is reading it wrong.

Mac Performance Monitor against Activity Monitor and Stats

Activity Monitor is the built-in comparison and the honest one. It is a live inspector with no recorder, which is exactly the gap this project targets: the README frames the app as something you use to go back to the moment a slowdown or spike began. If you only ever want to glance at current CPU load, Activity Monitor already does that, ships with the OS, and asks for no extra permissions. That is a real reason not to install anything.

Stats is the other name people search for in this space. The README does not compare the two, so the only defensible difference here is the one this project documents about itself: a history database you can return to, an Explorer workspace for comparing up to eight processes including exited ones, and alert rules built on continued growth or paging strain rather than a fixed swap threshold. Whether that matters depends on whether you have ever needed to answer the question "what was running when this started".

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-15. Releases are frequent: v2.1.0.236 on 2026-09-11, v2.0.0.231 on 2026-09-10, and v1.7.1.206 on 2026-09-03. The README links a changelog and release notes, and the upgrade section says existing alert choices and history carry forward from 1.x, that the old swap threshold is no longer used while explicit process-memory budgets remain, and that alert state is local and separate from full history recording.

The practical upgrade cost is small but not zero. Back up the app's data before testing a downgrade, and read the upgrade notes in CHANGELOG.md before moving between major versions. The project is MIT licensed, which is permissive and places few obligations on users; that is a statement about the licence text, not legal advice, and anyone redistributing the app or bundling it should read LICENSE themselves. Two operational notes from the repository: the project accepts translations through Crowdin, and the README asks you to review SECURITY.md before sharing trace files, reports or screenshots, since those may contain machine and process detail.

Editorial conclusion

Adopt it if you are on macOS 15 or later with an Apple silicon Mac and you want a local, MIT-licensed record of what the machine was doing when it slowed down, installed either from the Homebrew cask mac-performance-monitor or the notarized MacPerformanceMonitor.pkg. Skip it on Intel Macs and on macOS 14 or earlier, where the README's stated requirements rule it out, and skip it if you want a live readout only, since Activity Monitor already covers that without a recorder. Before relying on it, confirm that the menu bar and history recorder switches are independent, check whether Full Disk Access is required for the optional Apple app and media activity view you intend to use, and read the upgrade notes and SECURITY.md before sharing a trace file, report or screenshot.

Frequently asked questions

How can I check my Mac's performance with Mac Performance Monitor?

Enable the menu bar readout for a live view, or turn on the history recorder and open Explorer to pick a time and add the signals you need. Explorer can compare up to eight processes, including ones that have exited.

Is Mac Performance Monitor a better Activity Monitor for Mac?

It targets a different job: recording samples so you can return to the moment a slowdown or spike began, rather than only showing current activity. The README does not claim to replace Activity Monitor, and Activity Monitor needs no extra install or permissions.

How do I run a full diagnostic on my Mac with Mac Performance Monitor?

The app logs CPU, memory, GPU, network, disk, battery and sensor readings alongside the processes behind them, and can export visible Explorer data as CSV or share process history as a trace file. It is a recorder and inspector, not a one-click diagnostic suite.

Does Mac Performance Monitor clean up my Mac and make it run faster?

No. The README describes a performance monitor and recorder for diagnosing issues; it does not document cleanup, cache removal or optimisation features. Its alerts report continued growth or paging strain as observations rather than diagnosing a memory leak.

Official sources

  1. License: MIT
  2. Project website
  3. README
  4. Releases
  5. Zesty0wl/mac-performance-monitor on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/zesty0wl-mac-performance-monitor.svg)](https://hysenlabs.com/projects/zesty0wl-mac-performance-monitor)