Capture CPU and memory evidence for Mac bug reports

The short answer: note the wall-clock start, capture a stable reading before the action, run one repeatable action, record the peak or sustained state, and wait for recovery. Open Activity Monitor during that same workload when you need the process name, Memory Pressure, swap, CPU History, or a safe quit path. Do not infer an exact duration from a sparkline alone.

A report that says "my Mac got slow" is hard to replay. A report that says "at 10:14:20, opening this 2 GB project raised aggregate CPU from 12% to 84%; it remained above 70% after the export ended at 10:16:05" gives the maintainer a state, action, interval, and recovery failure to test.

Disclosure: I build teenystat. It is useful here because it keeps aggregate CPU, calculated used memory, and available fan speed visible, with short sparklines, per-core CPU detail, and session high/low values. It does not name processes or show Apple's Memory Pressure, swap, disk I/O, GPU usage, or quit controls. Use Activity Monitor for those jobs.

Capture one time-aligned evidence window

01Write down the workload and the clock

Start with the app and build, document or URL, exact task, Mac model, macOS version, power state, display setup, meeting software, screen recorder, local server, export, or other work that could affect load. A CPU number without that context can implicate the wrong app.

Record the wall-clock start and end. TeenyStat normally requests a new sample every three seconds, but it drops a scheduled tick when the previous collection is still running. Under heavy load, a 60-point sparkline is therefore roughly three minutes of observations only when every tick completes. It is not an exact timeline or an exportable log.

For the environment, repro, expected result, actual result, and attachment handoff, use the TeenyApps hub Mac bug report checklist for repro, evidence, and context. This TeenyStat guide covers the system-load branch.

02Let CPU establish a baseline before the action

TeenyStat calculates per-core CPU usage from the change in processor ticks between reads, then averages the per-core results for its aggregate value. The first successful read seeds the previous tick counters, so its CPU result can be near zero. Wait for later readings before calling anything a baseline.

Keep two stable readings, start one action, and note whether the aggregate value spiked briefly or stayed elevated. The per-core bars describe the shape of the same system-wide load, such as one hot core versus broad work. Neither view identifies the responsible process.

Session high and low values are useful bounds for the current app session, but they are not timestamped. Pair a high value with your clock note and screenshot. Otherwise the report cannot prove whether that high occurred during the repro or earlier.

03Treat used memory and Memory Pressure as different signals

TeenyStat calculates used memory from active, wired, and compressed memory reported by macOS, divided by physical memory. That is a consistent menu bar trend for this app. It is not Apple's Memory Pressure graph, and it does not show swap or the process holding memory.

Record whether the value began high, climbed only during the action, kept climbing across repeated actions, or returned toward baseline. Then use Activity Monitor's Memory pane when the report needs Memory Pressure, Physical Memory, Memory Used, App Memory, Wired Memory, Compressed, Cached Files, Swap Used, or per-process memory.

Fan RPM is supporting context only. Capture it when the Mac exposes a fan and omit it on fanless hardware. A fan can respond after CPU changes because thermal response lags the workload, so a delayed ramp does not establish which process caused it.

04Capture screenshots at baseline, load, and recovery

Take the smallest screenshot that proves each state without exposing unrelated private data. Include a clock or put the time in the filename. A single peak screenshot does not show whether the signal was already high or whether it recovered.

Do not report more precision than the evidence has. A sparkline shows direction and relative timing; your wall-clock notes establish duration. A session high shows that a value occurred sometime during the current session; the screenshot connects it to this action.

If the issue is visual as well as slow, pair the same reproduction state with the TeenyColor guide to report UI contrast bugs with source and rendered color evidence. Keep the visual defect and performance evidence distinct even when they share one report.

05Open Activity Monitor during the same workload

TeenyStat can show that the system signal moved. It cannot identify the process. Open Activity Monitor while the action or abnormal recovery state is still present. Sort by CPU for process-level processor evidence, use CPU History for system activity over time, or use the Memory pane for pressure, swap, and per-process memory.

Take one Activity Monitor screenshot that includes the selected view, sort order, process name, and relevant column. Keep the same wall-clock window in the issue so the aggregate signal and process evidence can be compared rather than treated as two unrelated snapshots.

If you decide to stop a process, use Apple's normal Quit path first. Force Quit can cause data loss and should be the last step, after the evidence is saved. The menu bar CPU monitor vs Activity Monitor guide covers this tool boundary in more detail.

06Describe recovery, not just the peak

High CPU during compiling, exporting, indexing, screen recording, or a virtual machine can be expected. The more useful question is whether the work completed and the system returned toward its starting state.

Use neutral observations: "CPU remained above its baseline after the export completed," "used memory rose with each repeat and did not return," or "the process stayed at the top of Activity Monitor while the app was idle." Threshold colors are local settings, so a red menu bar state is context, not proof of a defect.

Repeat only when it is safe and useful. If the same action creates the same signal and recovery failure twice, say so. If the issue risks data loss, overheating, or a customer-visible failure, preserve the first evidence and stop.

Bug report template

1. Environment: app build, file or URL, Mac model, macOS, power state, displays, and concurrent heavy work.
2. Reproduction: exact steps, start time, end time, and whether the result repeated.
3. Baseline: two stable aggregate CPU and calculated used-memory readings after CPU initialized.
4. Action: peak or sustained CPU range, per-core shape, used-memory direction, and fan RPM when available.
5. Recovery: task completion and whether CPU, used memory, and fan activity returned toward baseline.
6. Activity Monitor: view, sort order, process name, relevant CPU or memory value, Memory Pressure or swap when relevant, and responsiveness.
7. Expected result and actual result.
8. Attachments: baseline, load, recovery, and Activity Monitor screenshots, named with their wall-clock times.

Sources checked

• TeenyStat feature claims were checked against the TeenyStat homepage and local Swift source for the three-second default schedule, overlapping-tick guard, 60-point histories, CPU tick deltas, aggregate and per-core CPU, active plus wired plus compressed memory, fanless-Mac handling, and untimestamped session high/low values.
• 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 Developer: Feedback Assistant for issue summaries, reproduction steps, diagnostics, and attachments.
• Apple Support: Take a screenshot on Mac.

FAQ

What should I include in a Mac performance bug report?

Include the exact workload, wall-clock start and end, a stable baseline, readings during the action, a recovery check, Activity Monitor process or Memory Pressure evidence when needed, screenshots, and repeatable steps.

Can TeenyStat identify the process causing a slowdown?

No. TeenyStat shows aggregate CPU, calculated used memory, and available fan signals. Use Activity Monitor when you need process names, Memory Pressure, swap, CPU History, columns, and quit controls.

Should I quit apps before collecting evidence?

Usually no. Record baseline, action, and recovery first. If you need to identify a process, open Activity Monitor during the same workload before quitting it normally or force quitting as a last resort.