Mac app not responding but CPU is high: wait or quit?
A busy app can look frozen while it finishes real work. The trick is deciding when "not responding" means wait, when it means inspect, and when it means quit.
The short answer: if a Mac app is not responding but CPU is high during a known export, build, archive, render, or compression job, wait first. Watch CPU, memory, and fan trend for another minute. Open Activity Monitor when the load stays high or does not match the task. Try normal Quit before Force Quit when files may be open.
Disclosure: I build teenystat, a Mac menu bar app for CPU usage, memory usage, fan speed, per-core load, thresholds, and alerts. It is good for the first signal. It does not name processes or replace Activity Monitor's quit controls.
Quick wait-or-quit table
| What you see | Likely meaning | Best next step |
|---|---|---|
| CPU high during a known task | The app may still be exporting, rendering, compressing, or indexing. | Wait and watch trend before interrupting it. |
| CPU high with memory pressure stable | The task is processor-heavy, but the app mix is not obviously choking memory. | Give it a short window, then inspect in Activity Monitor if progress is unclear. |
| CPU low, no progress, app still red | The app may be stuck without useful work happening. | Open Activity Monitor and inspect the process before quitting. |
| Memory pressure rises or swap climbs | The app or current workload may be forcing macOS into memory recovery work. | Use Activity Monitor's Memory pane before force quitting. |
| Fan keeps rising after the task should be done | A background process or helper may still be working. | Sort by CPU in Activity Monitor and find the process name. |
01Wait when high CPU matches known work
A Mac app can stop repainting its window while it is still doing useful work. That is common during exports, big PDF generation, photo processing, archive creation, builds, code indexing, and some uploads. If CPU is high during that exact task, waiting is often the least risky move.
Use teenystat as the first read. The app's Swift source reads CPU load with host_processor_info, computes usage from tick deltas, shows aggregate CPU, and includes per-core shape in the popover. It also keeps CPU next to memory and fan speed, which matters because CPU alone can mislead you.
If the busy task is archive creation, use the Mac ZIP compression troubleshooting guide before you cancel a slow archive or start a duplicate ZIP.
I use a short rule: watch the trend for 30 to 60 seconds. If CPU stays high and the task has a plausible reason to be busy, do not interrupt it yet. If the same app has no progress, no output file growth, and no visible reason to be busy, move to Activity Monitor.
02Open Activity Monitor when you need names
TeenyStat answers "is the Mac under load?" Activity Monitor answers "which process is doing it?" That distinction matters when an app is not responding. You need process names, columns, grouping, search, and the Stop button before you decide what to kill.
Apple documents that Activity Monitor can show process information, sort columns, search for a process, group processes, and display CPU activity. It also marks an unresponsive process as "Not Responding" and offers Quit and Force Quit. Apple's own warning is blunt: Force Quit can lose data if the process has files open and can affect other apps if they depend on that process.
If a client handoff or export is involved, use the TeenyApps hub Mac client handoff checklist before you send the final files. It covers the system-load and file-staging side together.
03Try normal Quit before Force Quit
Normal Quit asks the app to stop safely. Force Quit ends the process immediately. That difference matters when the app may be writing a zip, saving a PDF, exporting a video, syncing a project, or writing a database.
Activity Monitor gives you both options from the Stop button. Pick Quit first when data loss would matter. Use Force Quit when the process is clearly wedged, the output is disposable, or the system is stuck enough that waiting is no longer useful.
If you force quit, treat the current output as suspect. Reopen the source file, rebuild or re-export if needed, and check the destination before you send anything to a client.
04Pair CPU with memory and fan trend
High CPU can be healthy. High CPU plus rising memory pressure is more worrying. High CPU plus fan ramp can be normal during a render, but odd after the job ends. CPU calm with memory pressure high points somewhere else.
TeenyStat keeps those signals close. Its local source reads memory through host_statistics64, calculates active, wired, compressed, used, and free memory, and reads fan speed through SMC on Macs with fans. That quick context tells you whether Activity Monitor should open to CPU, Memory, or a specific process search.
For the broader split between a menu bar signal and Apple's process tool, read Mac menu bar CPU monitor vs Activity Monitor. For memory interpretation, use Mac memory pressure vs memory used.
05Write down what happened if this affects a deadline
If the stuck app affects a client delivery, a release, or a support ticket, capture the state before it disappears. Write the app name, file name, task, CPU trend, memory pressure, fan trend if available, and the action you took. A one-minute note is better than reconstructing the failure later.
Use Capture CPU and memory evidence for Mac bug reports when the problem may become a report. If the issue was only a one-time export delay, the note still helps you decide whether to change the workflow next time.
Do not turn every busy app into a bug report. Most of the time, the right answer is boring: wait, inspect, quit safely, rerun the task, and verify the output.
Five-step wait-or-quit routine
- Name the task the app is supposed to be doing.
- Watch CPU, memory, and fan trend for 30 to 60 seconds.
- Open Activity Monitor if the load is sustained, unexplained, or risky.
- Try normal Quit before Force Quit when files may be open.
- Verify or recreate the output before sending it anywhere.
Common questions
Should I force quit a Mac app that is not responding but using CPU?
Not immediately. If CPU is high and the app is doing a known export, build, archive, or render, wait and watch the trend. Use Activity Monitor before force quitting because Force Quit can lose unsaved data or disrupt related processes.
Can TeenyStat tell me which Mac app is not responding?
No. TeenyStat shows CPU, memory, fan speed, and trend signals. Use it for the first read, then use Activity Monitor when you need the process name, columns, or quit controls.
What signs mean I should stop waiting?
Stop waiting when CPU drops to idle with no progress, memory pressure or swap keeps climbing, the process has no visible output, or the same app has been stuck long enough that the work is no longer moving.
Sources checked
- TeenyStat feature claims were checked against the TeenyStat homepage and local Swift source for CPU reads, memory reads, fan reads, aggregate CPU, per-core CPU, menu bar metrics, and polling behavior.
- Apple Support: View CPU activity in Activity Monitor on Mac.
- Apple Support: View information about Mac processes in Activity Monitor.
- Apple Support: Quit an app or process in Activity Monitor on Mac.
- Apple Support: View memory usage in Activity Monitor on Mac.
See load before you make the quit call.
teenystat shows CPU, memory, and fan speed in your Mac menu bar, with thresholds, sparklines, and per-core CPU detail when you need a closer look.