Free up a Mac before a video call without quitting apps

To free up a Mac before a video call without losing any work, pause the busy background apps instead of quitting them. Find them in Activity Monitor, sorted by % CPU, and run kill -STOP PID for each. A paused app uses 0% CPU, keeps its windows and its state, and kill -CONT PID after the call brings it back exactly where it was. Do not pause the call app itself, or anything it needs: audio, the browser tab with the call, the system.

Most guides on this topic tell you to close apps and tabs. That works, but it throws away what is running: a build, an export, a download, a half-written message. Pausing keeps all of it.

Before the call: five steps

1. Open Activity Monitor and click the CPU tab, then the % CPU column. The busiest processes come first.
2. Mark the ones that belong to the call and leave them alone: the call app, the browser if the call runs in it, and anything that carries your sound or camera.
3. Pick the busy ones that are not part of the call: a build, a video export, a sync client, a browser with a heavy tab, a Docker container. Note each PID (the PID column).
4. Pause each: kill -STOP 1234. To pause every process with one exact name: killall -STOP "Docker". Check with ps -o stat= -p 1234: the letter T means stopped.
5. After the call, resume: kill -CONT 1234, or killall -CONT "Docker".

A paused app does not resume on its own. Until you send kill -CONT or quit it, it stays frozen, so write down what you paused. More on how this works in how to pause a process on Mac.

What a pause gives the call: my measurement

I wanted to see what freezing background work does for something that needs steady timing, which is what a call does. This is a stand-in, not a real call: I did not run Zoom, Meet or Teams.

Setup: a MacBook Air with Apple M2 (8 cores), macOS 15.7.7, 2026-10-17. Eight processes each kept one core busy, to stand in for a build, an export and a few heavy tabs. A separate process asked to wake up every 10 ms, 400 times, and recorded how late each wake-up was. It also timed one fixed chunk of computing. I ran three rounds, alternating the eight busy processes paused (kill -STOP) and running.

Eight busy background processes	Late wake-ups, 95th percentile	Latest wake-up	Fixed computing
Running (3 rounds)	7.3 to 9.7 ms	18 to 102 ms	0.30 to 0.43 s
Paused (3 rounds)	2.5 to 2.6 ms	3 to 30 ms	0.27 to 0.30 s

Every row has the same median lateness, about 2.5 ms: that is the base delay of the timer on this Mac. What changed is the tail: with the background load running, one wake-up in twenty was 7 to 10 ms late, and the worst ones were 18 to 102 ms late. With the load paused, the 95th percentile stayed at the base level, and the worst case was 3 ms in two rounds and 30 ms in one. I did not find the cause of that one 30 ms outlier. The resume also worked: a paused process added no CPU time while stopped (17.27 s before and after) and kept counting after kill -CONT (18.85 s).

What this shows: a busy background load makes timing uneven, and pausing it brings the timing back. What it does not show: how much a real call improves. Real call apps lean on the video encoder and the GPU, so the gain from freeing the CPU may be smaller than here. I measured one Mac and one stand-in workload.

What not to pause

• The call app and its helper processes. Search the app name in Activity Monitor to see all of them.
• The browser with the call tab. Pausing the browser freezes the call. Pausing only the other heavy tabs is fine, see Chrome Helper (Renderer) high CPU.
• Music and anything that plays sound. Playback stops while the app is paused.
• System processes. WindowServer draws the screen, and stopping it can freeze the display. Aide refuses to pause it and a few other login and system processes.
• A download or a sync you cannot interrupt. A paused app cannot answer the network, so its connections can time out. Pause it only if you can resume it in a short time.

Chat apps are a judgement call. A paused chat app will not show notifications, and what arrived should appear after you resume it. I did not test this on a specific chat app.

Pause in Aide

Aide lists the apps that load your Mac and puts a Pause button on each row. Pause freezes that app at once, no confirmation. A paused row stays in the list until you click Resume, so you do not forget it after the call. The same works from the keyboard: pick a row with the arrow keys, then press P or Space. Two limits: Aide pauses one app at a time, there is no "pause everything" button, and it does not know that you are on a call, so you decide what stays running.

FAQ

Is pausing safe for my files? The app keeps everything in memory exactly as it was and continues from the same place after kill -CONT. If the app was in the middle of writing a file when you paused it, the write simply waits. If you are not sure, wait for it to finish.

Does pausing free memory? Not reliably. Pausing frees the CPU. In my earlier test the memory footprint did not change, and only the resident part dropped. If memory is the problem, quit the app: how to pause a process on Mac has the numbers.

Why is my Mac fan loud during calls? It can be the call app itself, other load, or both. One author who tracked fan noise in Microsoft Teams on a 2019 MacBook Pro found that it did not show up in Zoom or Webex, and that turning off GPU hardware acceleration in Teams helped (dbi-services). To tell whose load it is, sort Activity Monitor by % CPU during the call. If a background process is on top, pause it. If the call app is on top, pausing others will not help much. For a hot Mac in general, see why is my Mac slow and hot.

What can I use instead of a pause? Quitting apps frees everything but loses what is running. Closing browser tabs helps with the browser only. A pause is the middle path: the CPU is free, the work stays.

Sources

• My own measurement: MacBook Air (Apple M2, 8 cores), macOS 15.7.7, 2026-10-17. Eight busy processes, kill -STOP and kill -CONT, a 10 ms wake-up test, ps
• dbi-services: macOS reduce fan noise when using Microsoft Teams
• ForceNap, issue 6: ideas from users, including "when switching foreground app to fullscreen mode nap all other background apps"
• Apple Support: Activity Monitor User Guide