Bosun vs Activity Monitor: why the built in tool cannot answer port questions

When something is stuck on a port, plenty of people open Activity Monitor first. It is already installed, it lists every running process, and it has a Network tab. It feels like the right place to look.

It is not, and the reason is structural rather than a missing feature.

Activity Monitor is a process viewer, not a network viewer

Its five tabs are CPU, Memory, Energy, Disk and Network. The Network tab is about volume, how many bytes and packets each process has sent and received. That is useful when you want to know which app is chewing through your connection.

It says nothing about which ports a process is listening on. There is no port column, no way to sort by port, and no way to search for one. So the question you actually have, “what is sitting on 3000”, has no answer in that window.

You can get close with guesswork. Find the node process you think is the culprit, select it, force quit it, and see whether the port frees up. That works, sometimes, and it is why the approach survives. It also means killing processes by hunch, which is how people lose unsaved work in a build they did not mean to stop.

The reverse direction is the problem

Activity Monitor answers “what is this process doing”. Port debugging needs the opposite, “which process owns this port”. Going backwards from a port number to a process is exactly what it cannot do.

That is why the standard answer is Terminal:

lsof -i :3000

lsof goes in the right direction. It starts from the port and gives you the process. If you are comfortable in a terminal, that command plus kill covers most of this, and we wrote an honest comparison of Bosun against lsof rather than pretending otherwise.

Three things neither tool will tell you

Activity Monitor and lsof share the same blind spots, and they are the ones that tend to matter.

Which container. Docker publishes every container port through a process called docker-proxy. Activity Monitor shows several identical rows with that name. Nothing in either tool tells you which of your containers is behind each one.

Whether a tunnel is open. An ngrok or cloudflared tunnel is a live path from the public internet to your laptop. It is not a listening port in any form that identifies it as a tunnel, so it is invisible in both tools. A tunnel you forgot to close is a real security problem, not just untidiness.

What was running ten minutes ago. Both tools are strictly live views. If a process grabbed a port and exited before you looked, there is nothing left to see.

What Bosun does differently

Bosun lives in the menu bar and starts from the port, not the process. It lists everything listening, grouped by port number, with the process that owns each one. Docker rows show the real container image and Compose project instead of docker-proxy. Tunnels appear with their public URL. VPN status is visible. A history keeps what was listening earlier, so a port that came and went is still there when you go looking.

Terminating is explicit rather than a guess. Bosun sends SIGTERM first and only escalates to SIGKILL if the process refuses to exit, which is the same courtesy a plain kill gives you and the opposite of Force Quit.

Which to use

Activity Monitor is the right tool for CPU, memory, energy and disk, and it is not going anywhere. Keep it for that.

For “what is on this port”, the answer is lsof if you like the terminal, and Bosun if you would rather have it already visible, with containers and tunnels named properly.

Bosun requires macOS 14 or later. The 14 day trial starts when you open it, no account needed.