How to monitor Mac performance over time

Define the event before collecting data

Write down what you actually noticed: a delayed click, a spinning pointer, a hot chassis, a loud fan, a stalled transfer, or an app that stopped responding. Record the approximate time and whether the Mac was starting up, waking, exporting, syncing, compiling, or otherwise doing expected work.

This prevents a normal workload peak from being mistaken for a fault. It also gives you a timestamp to compare with CPU, memory, and temperature changes.

Use Activity Monitor for the live view

Activity Monitor lets you change its update frequency. A faster refresh can make short changes easier to see, but Apple notes that increasing the frequency can itself use more system resources. Use the default unless the event is too brief to capture.

1. Open Activity Monitor and select CPU.
2. Use Window → CPU History to see recent processor activity across the Mac.
3. Open Memory when the symptom involves stalls or slow app switching, and check Memory Pressure rather than free memory alone.
4. Keep the relevant pane visible while you repeat the action that caused the problem.

Build a repeatable before-and-after timeline

A timeline is more useful than a single maximum value. If CPU rises exactly during a video export and falls when it completes, the reading matches the work. If memory or CPU remains elevated long after the task ends, the process deserves closer inspection.

1. Observe the Mac for a short baseline period before starting the workload.
2. Start one task and note its exact start time.
3. Wait for the symptom, then note when it ends.
4. Change only one variable, such as closing one app, and repeat the same workload.
5. Compare the shape and timing of the second run with the first.

Preserve up to 24 hours with KernPulse

While KernPulse is running, it records overall CPU use, memory use, and available temperature readings every 30 seconds, even when its panel is closed. You can switch among 30-minute, 1-hour, 6-hour, 12-hour, and 24-hour views. Longer windows preserve peaks instead of averaging them away, and missing samples remain visible as gaps.

You can also pin up to three process names. A pinned process gets a separate one-hour CPU trend at 30-second resolution, which helps test whether the same app repeatedly becomes active before the system-level spike.

Know what the history does not prove

The 24-hour view is system-level history, not a complete archive of every process. KernPulse does not keep 24-hour per-process memory, network, GPU, or energy histories. Pinned history covers CPU only, and restarting KernPulse starts a new in-memory timeline.

Use the history to identify the time and resource involved, then use Activity Monitor or the affected app’s own diagnostics for deeper attribution.