Port 3000 is busy and your fans are spinning

By the maker of WTMemory · Updated Sept 2026

Every developer has met the zombie dev server: a Vite or Next.js process started days ago, in a terminal tab since closed, in a project folder since deleted - still holding port 3000, still eating 1-2 GB of RAM, still burning battery. Here is how to hunt them properly.

Find what is holding the port

lsof -i :3000

That returns the PID. Then, for detail before you kill it:

ps -p <pid> -o pid,ppid,etime,%mem,command

etime is the killer column: a dev server that has been running for 3-12:41:07 is almost certainly something you forgot about.

Kill it properly

kill <pid>          # SIGTERM: lets it shut down cleanly
kill -9 <pid>       # SIGKILL: only if it ignores the first one

Reach for -9 second, not first. Vite and Next.js flush caches on a clean shutdown; SIGKILL can leave stale lock files that make the next start confusing.

Find the ones you cannot see (orphans)

Orphans are not bound to any port you remember, so lsof will not find them. Look by process name instead:

ps -axww -o pid,etime,%mem,command | grep -Ei "vite|next-server|nodemon|workerd|esbuild|tsx watch" | grep -v grep

Each line shows how long it has been alive. Anything older than your current work session is a candidate.

Why they survive at all

Killing the terminal window does not kill its children reliably, and tools like nodemon, turbo and watchman deliberately detach to keep watching files. Add the modern stack - local LLM runtimes, MCP servers, browser automation - and a "clean" dev Mac can idle at 4 GB of RAM with nothing visibly open.

The 10-second version, one click

If you would rather not hunt PIDs every time: WTMemory sits in your menu bar and has a Kill Dev Servers action that finds all of the above by pattern and terminates them gracefully - plus a live RAM readout so you can see the 2 GB come back.