Capture CPU and memory evidence for Mac bug reports
A useful performance bug report shows what the Mac was doing, how long the load lasted, and when Activity Monitor confirmed the process-level evidence.
The short answer: capture the workload, watch CPU, memory, and fan trend before you quit anything, then open Activity Monitor when you need process names, memory pressure, or a safe quit path. A report that says "my Mac got slow" is hard to fix. A report that says "CPU stayed above 80 percent for two minutes while this window was idle" gives the next person something to test.
This guide is for product teams, support tickets, and internal issue trackers. It is not a benchmark recipe. The goal is to preserve the system state long enough to describe it accurately.
Disclosure: I build teenystat. The app is useful here because it keeps CPU usage, memory usage, and fan speed visible in the menu bar, with sparklines, threshold colors, per-core CPU detail, and session high/low values. It does not show process names, memory pressure, swap, disk I/O, GPU usage, or a quit button. That is where Activity Monitor belongs.
Quick evidence table
| Evidence | Use TeenyStat for | Use Activity Monitor for |
|---|---|---|
| CPU | Visible current load, trend, session high/low, and per-core shape. | Process names, CPU columns, CPU History, and inspection. |
| Memory | Current memory usage, trend, and whether the value keeps climbing. | Memory pressure, swap, compressed memory, and process-level memory. |
| Fan | Fan RPM trend when the Mac has fans. | Context only. Activity Monitor does not replace thermal diagnosis. |
| Repro window | Quick before-and-after screenshots of the visible system signal. | Evidence that identifies the process during the same window. |
| Fix action | Deciding whether the signal is worth interrupting. | Quitting or force quitting a selected process safely. |
01Write down the workload first
Performance evidence starts with context. List the app, document, meeting app, browser tabs, external display, screen recorder, local server, or export job that was running when the problem appeared. Add whether the Mac was plugged in, on battery, recently woken, or already hot.
Do this before closing windows. If you quit the workload first, the numbers may settle and the report turns into memory. Keep the evidence window short, but preserve the state long enough to describe it.
For a broader issue template, use the TeenyApps hub Mac bug report checklist for UI and performance issues. This TeenyStat page is the system-load spoke.
02Capture CPU, memory, and fan trend together
One metric can mislead. CPU can spike during expected work and then settle. Memory can rise while CPU stays calm. Fan speed can lag behind the actual load because heat takes time to build and time to leave.
TeenyStat reads CPU with macOS processor load information, reads memory with host memory statistics, and reads fan speed through SMC data when the Mac exposes fans. Its dashboard keeps short sparkline histories and session high/low values. That is enough for an issue comment: "CPU stayed high," "memory climbed during the repro," or "fan RPM rose after the export started."
On fanless Macs, leave fan evidence out. TeenyStat detects fanless hardware and should not make a missing fan sensor look like a performance bug.
03Take screenshots before the state disappears
Use a screenshot to freeze the window, the visible TeenyStat value, and the timing of the issue. Apple's screenshot shortcuts are enough. Capture the smallest area that proves the state without exposing private data you do not need to share.
If the issue is visual as well as slow, pair this with the TeenyColor guide to report UI contrast bugs with color evidence. A single bug can need both kinds of proof: one screenshot for the UI state and one system-load note for why the app felt stuck.
Do not rely on screenshots alone. A screenshot of a high CPU value is useful only when the report also explains what was running and whether the value was sustained.
04Open Activity Monitor when names matter
TeenyStat can tell you that the Mac is busy. It should not claim to know which process is guilty. Open Activity Monitor when you need to sort by CPU, inspect memory pressure, see process-level memory, or quit an app or helper safely.
When you open Activity Monitor, keep the same workload running long enough to capture the relevant process evidence. Sort by CPU for processor load. Use the Memory pane when memory pressure or per-process memory is the better clue. If you decide to quit a process, use Apple's normal quit flow before force quitting anything that may hold unsaved work.
For the exact boundary between a menu bar signal and Apple's diagnostic app, see Mac menu bar CPU monitor vs Activity Monitor.
05Separate expected load from abnormal load
A bug report should not treat every high number as a defect. Video export, compiling, indexing, virtual machines, screen recording, browser restores, and large design files can all use CPU and memory legitimately.
Use decision language instead of alarm language. Say "CPU stayed high after the export completed," "memory kept climbing while the app was idle," or "fan speed rose while the same screen was open and no background work was running." That distinction helps the maintainer test the same condition.
Threshold colors can help, but they are not the whole report. TeenyStat thresholds are local settings. A red state on your machine is useful context, not proof by itself.
Bug report template
- App, screen, document, or task being performed.
- Mac model, macOS version, power state, display setup, and whether a meeting or screen recorder was running.
- CPU trend: current value, sustained range, session high, and whether one core or all cores were busy.
- Memory trend: current usage, whether it kept climbing, and Activity Monitor memory pressure if checked.
- Fan trend: RPM range if the Mac has fans.
- Activity Monitor evidence: process name, CPU or memory column, and whether the process was responsive.
- Expected result and actual result.
- Screenshot or screen recording, cropped to the necessary state.
Sources checked
- TeenyStat feature claims were checked against the TeenyStat homepage and local Swift source for CPU reads, memory reads, fan speed reads, menu bar metric selection, fanless-Mac handling, sparklines, per-core CPU detail, session high/low values, thresholds, and alerts.
- Apple Support: View CPU activity in Activity Monitor on Mac.
- Apple Support: View memory usage in Activity Monitor on Mac.
- Apple Support: Quit an app or process in Activity Monitor on Mac.
- Apple Support: Get started with Feedback Assistant on Mac.
- Apple Support: Take a screenshot on Mac.
FAQ
What should I include in a Mac performance bug report?
Include the workload, time window, CPU trend, memory trend, fan trend when available, Activity Monitor process evidence, screenshots, and a short repro.
Can TeenyStat identify the process causing a slowdown?
No. TeenyStat is a first-pass system monitor. Use Activity Monitor when you need process names, memory pressure, columns, and quit controls.
Should I quit apps before collecting evidence?
Usually no. Record the visible CPU, memory, and fan state first, then use Activity Monitor if you need to identify or quit a process safely.
Keep the evidence visible before it disappears.
teenystat shows CPU, memory, and fan speed in your Mac menu bar, with thresholds, sparklines, per-core CPU detail, and session high/low values for quick triage.