Guide: use the app to identify and free a blocked local port.

This page is written against the current downloadable desktop build and source tree. It focuses on the day-to-day tasks the app is actually designed for, not generic networking theory.

  • Updated: 2026-03-09
  • Audience: developers and system administrators
  • Current public app version: 1.0.0

Quick start

  1. Open WhoUseMyPort and let the first scan finish.
  2. Use the search box to type a port number, process name, PID, or command fragment.
  3. Check the protocol and state columns so you know whether you are looking at a listener or a short-lived connection.
  4. Inspect the process name and command before you stop anything.
  5. If you decide the process should end, use the terminate action and expect the operating system to ask for permission when needed.

If you only remember one rule, make it this one: never kill a process based on the port number alone. The command and state columns are what turn a fast guess into a reliable decision.

Read the table correctly

Port

The local port number currently associated with the socket entry you are inspecting.

Protocol

Useful when you only want to see TCP listeners or isolate UDP activity.

State

Helps separate listeners such as LISTEN from normal traffic such as ESTABLISHED or sockets that are winding down.

Process

The display name of the local process that owns the PID.

PID

The operating-system process identifier you can cross-check elsewhere if needed.

Command

The best field for telling apart similar process names, especially multiple Node, Python, Java, or database instances.

The current UI also supports search, protocol and state filtering, sortable columns, and auto-refresh intervals. Public builds expose refresh presets from 3 seconds to 60 seconds, which is useful when you are waiting for a listener to disappear or for a service to restart cleanly.

Common workflows

Free port 3000 or 8080 after a crash

  1. Search the port directly.
  2. Read the command line to confirm which local project still owns it.
  3. If the process is stale, terminate it. If it is a healthy service, restart that service normally instead.

Check whether a database is still listening

  1. Search the expected port.
  2. Look for LISTEN rather than assuming any matching entry means the server is active.
  3. Use the process and command fields to distinguish the database from clients connected to it.

Watch short-lived connections

  1. Turn on auto-refresh.
  2. Filter to a protocol or state if the list is noisy.
  3. Watch how the socket state changes before treating the behavior as a failure.

Check if a kill action really worked

  1. Refresh after the action completes.
  2. Confirm that the PID disappeared or the port is no longer owned by that process.
  3. If the PID remains, the operating system may have denied the action or another service may have restarted immediately.

Use the OpenClaw workflow

  1. Reduce the table to the rows that matter by searching a port number, PID, or command fragment.
  2. If your build includes Export for OpenClaw, export the current view after filters are set.
  3. Paste the report into OpenClaw after enabling the bundled whousemyport-port-diagnostics skill.
  4. Ask a concrete question: which PID owns port 5173, whether port 5432 is safe to stop, or why a listener keeps returning.
  5. Call out active filters when you share the report so OpenClaw does not assume the table is complete.

If you are on the current public binary and the export button is not available yet, provide the same fields manually or use the current source build documented on the OpenClaw workflow page.

Before you terminate a process

  • Make sure the command line belongs to the app or service you actually mean to stop.
  • Check for unsaved work or stateful services that should be shut down cleanly first.
  • Remember that system services, security tools, databases, and container runtimes may own critical ports.
  • If the process is already exiting, refreshing once or twice can be safer than forcing another action.
  • Expect the OS to require elevated permissions for protected or cross-user processes.

The app is intentionally opinionated about local inspection, not bulk process management. If you need mass automation or remote control, use your existing terminal or orchestration tooling instead.

How the data is gathered

The documentation on this site is based on the current implementation in the application code, not generic placeholders. Today that means:

  • macOS scans rely on lsof -i -P -n.
  • Windows scans rely on netstat -ano.
  • Process details are resolved locally for each PID so the UI can show more than a bare number.
  • Windows termination uses taskkill.
  • Unix-like termination attempts a graceful signal before escalating when needed.

That local-first technical path matters because it explains both the value and the limits of the product. WhoUseMyPort is fast for the machine in front of you because it is not trying to be a remote scanner, asset inventory tool, or cloud dashboard.

When terminal commands are still better

  • When you need to script the same action across multiple machines.
  • When you are connected over SSH and do not have access to the desktop app.
  • When you need advanced text processing or to pipe results into another command.
  • When the target environment is Linux and you do not want to build the app yourself.

If that sounds like your situation, this site can still help by explaining what the GUI is reading and why. For installation, permissions, or troubleshooting notes, continue to the support page.