`ps aux` Is Still the Right First Look When Your Machine Feels Wrong and You Do Not Know Why

Why this command still earns its place: when a machine feels slow, noisy, or just “off,” the fastest useful move is often to inspect what is actually running instead of restarting things blindly.

What ps aux gives you

The ps command reports process status. The OpenBSD manual documents the various display modes, and the familiar ps aux form remains popular because it produces a broad snapshot of current processes.

A simple run:

ps aux

can tell you a lot very quickly:

1. what is running
2. who owns it
3. how much CPU it is using
4. how much memory it is using

That makes it a strong first-step command when your system or workflow feels unexpectedly heavy.

Why this is better than guessing

Developers often jump straight to “Docker is probably the issue” or “Chrome must be leaking again.” Sometimes they are right. Often they are guessing from habit, not evidence.

ps aux gives you a snapshot before the story gets invented. That matters because performance frustrations can come from:

1. a runaway dev server
2. a stuck build tool
3. a duplicated background watcher
4. a child process you forgot existed

If you do not inspect the process list, you can spend time optimizing the wrong suspect.

How to make the output manageable

Raw output can be long, so pair it with filtering:

ps aux | grep node
ps aux | grep python
ps aux | grep docker

Or sort by CPU with other tools if needed. The important point is not that you stare at every process forever. It is that you turn a vague machine feeling into a concrete list of candidates.

A practical debugging example

Suppose your MacBook fan is loud and your terminal workflows feel sluggish. Before closing random apps, check the process snapshot. If a watch mode, simulator helper, local model server, or forgotten background script is eating CPU, you will see it much faster than by blaming the whole machine.

That is exactly what makes ps useful. It shortens the gap between symptom and probable owner.

Why process ownership matters

The USER column is not decorative. It helps you tell whether the process belongs to your current work, another login session, or a system component. That can change whether you should stop it, ignore it, or escalate carefully.

Process debugging is not only about resource numbers. It is about knowing what you are actually looking at.

When this should be your first move

Reach for it when:

1. your machine suddenly feels slow
2. a local tool seems to have multiplied itself
3. a port or file lock issue suggests a leftover process
4. you want a broad process snapshot before using more specific tools

It is a first look, not the whole diagnosis. That is exactly why it is so useful.

Final recommendation

When your development machine feels wrong and you do not yet know why, run ps aux before random restarts. A process snapshot will not answer every question, but it gives you a much more honest starting point than frustration-based guesswork.

Sources

• ps OpenBSD manual