PM2 Process Manager: Manage PM2 Without the Command Line
The PM2 tab lists every PM2 process on your server with live CPU, memory, and restart counts. Restart, reload, start, stop, or delete any of them with one click, expand a cluster to see its instances, and stream a single process's logs live. No pm2 commands, no SSH session.
If you run Node apps on a server, you already know the loop. SSH into the box, run pm2 list to see what is alive, squint at the table, run pm2 restart <name>, then pm2 logs <name> to find out whether that actually fixed anything. Every check is a command, and every command needs a shell.
The PM2 tab replaces that loop. Connect to a server and every process PM2 keeps alive is listed for you, with live CPU, memory, and restart counts. Restart, reload, start, stop, or delete any of them with one click. Click a process and you get its metrics, its Node.js runtime internals, and a live log stream in the same panel. Apps you shipped through Deployments run under PM2, so they show up here automatically. For whole log files rather than one process's output, use the Logs tab, and for server-wide CPU and memory see Infrastructure Details.
What you can do in the PM2 tab
- See every process PM2 is managing on the server, with live status, CPU, memory, and restart count.
- Read totals for online, errored, and stopped processes at a glance, plus total CPU and memory.
- Restart, reload, start, stop, or delete any process with one click.
- Restart every process on the server at once.
- Save the current process list so it survives a reboot.
- Install PM2 on a server that does not have it, without opening a shell.
- Open any process to see CPU, memory, event loop lag, heap usage, restarts, and uptime.
- Check Node.js runtime internals like active handles, heap size, and event loop latency p95.
- See the auto-restart rules a process is running under.
- Stream a single process's logs live, and filter them as they arrive.
- Expand a cluster to see and manage each of its instances individually.
Why a PM2 tab instead of pm2 commands
| Doing it by hand | Doing it in CtrlOps |
|---|---|
ssh user@host, then pm2 list to see what is running | Click the server, click the PM2 tab |
| Count the online and errored rows yourself | The summary cards do it for you |
pm2 restart <name> | Click the restart button on the row |
pm2 reload <name> | Click the reload button on the row |
pm2 stop <name> and pm2 start <name> are two commands | One button that flips with the process state |
pm2 delete <name> | Click the trash icon |
pm2 restart all | Click Restart all |
pm2 save | Click Save list |
pm2 monit, which holds the terminal hostage | Live metric cards you can leave open |
pm2 logs <name> in a second SSH session | Open the process and switch to its Logs tab |
pm2 describe <name> and read a wall of text | The Overview tab, laid out and labelled |
Open the PM2 tab
Connect to your server
Open CtrlOps and click the server you want to manage. Wait for the header to show Connected.
Click the PM2 tab
In the left sidebar, click PM2. It sits between AI Terminal and Infra Details.
Read the process list
Every process PM2 is managing appears in the table, with the summary cards above it showing how many are online, errored, and stopped.
The panel header confirms the state of PM2 itself, showing PM2 · running next to the title once CtrlOps has found the binary and talked to the daemon.
If PM2 is not installed
Not every server has PM2 on it. If CtrlOps cannot find a pm2 binary, the tab shows PM2 is not installed instead of a process list, and offers to install it for you.
Open the PM2 tab on that server
Click your server, then click PM2 in the left sidebar. If no pm2 binary is found, CtrlOps shows the PM2 is not installed screen.
Click Install PM2
Click the green Install PM2 button in the middle of the panel. CtrlOps installs PM2 globally on the server.
Wait for the process list to appear
When the install finishes, the empty state is replaced by the process list. On a fresh install the list is empty until you start something.
PM2 needs Node.js on the server. If the install does not complete, open the AI Terminal and run node -v to confirm Node is there first.
Read the summary bar
Five cards sit above the process list. They are the fastest way to tell whether the server is healthy before you read a single row.
| Card | What it tells you |
|---|---|
| Online | How many processes are running right now. |
| Errored | How many have crashed or failed to start. Anything above zero is worth opening. |
| Stopped | How many are registered with PM2 but deliberately not running. |
| Total CPU | Combined CPU across every PM2 process on the server. |
| Total Mem | Combined memory across every PM2 process on the server. |
Total CPU and Total Mem cover PM2 processes only, not the whole machine. For server-wide load, use Infrastructure Details.
The process list
Each row is one process PM2 is managing.
| Column | What it shows |
|---|---|
| ID | The PM2 process id, the same number pm2 list prints. |
| Name | The process name, with the script it runs underneath it, such as app.js, index.js, or bash. |
| Status | ONLINE, ERRORED, or STOPPED, with a coloured dot. |
| Mode | fork ×1 for a single process, cluster ×4 for a clustered app and its instance count. |
| CPU | Live CPU use for that process. |
| Memory | Live memory use for that process. |
| ↺ | How many times PM2 has restarted it. Colour-coded, so a high count stands out. |
| Actions | Restart, reload, start or stop, and delete. |
The restart count is the single most useful column on this page. A process sitting at 120 restarts is not healthy just because it currently reads ONLINE - PM2 has simply caught it 120 times. Open it and read its logs.
Act on a process from the list
Find the process in the list
Scan the Name column for your app. The script file it runs, such as app.js or index.js, is shown underneath the name.
Pick an action from the Actions column
Each row ends with restart, reload, start or stop, and delete buttons. Click the one you want.
Watch the row update
The row updates in place with the new status, CPU, memory, and restart count, so you can confirm the action took effect without leaving the tab.
The four buttons, left to right:
| Button | Equivalent command | What it does |
|---|---|---|
| Restart | pm2 restart <name> | Stops the process and starts it again. Brief downtime. |
| Reload | pm2 reload <name> | Replaces the process without dropping requests. |
| Start / Stop | pm2 start / pm2 stop | One button that flips with the state. A stopped or errored process offers start, a running one offers stop. |
| Delete | pm2 delete <name> | Removes the process from PM2 entirely. |
Restart or reload? Restart kills the process and brings it back, so there is a short window where it serves nothing. Reload swaps it out while it keeps serving. Reload only genuinely avoids downtime in cluster mode, where PM2 has other instances to hold the traffic. On a fork ×1 process there is only one worker, so reload behaves much like a restart.
Delete removes the process from PM2's list. The app stops and PM2 forgets about it, so it will not come back on reboot. Your files on disk are untouched, but you will need to start it again yourself.
Restart every process at once
The green Restart all button at the top right restarts every process PM2 is managing on that server. It is the equivalent of pm2 restart all.
This hits everything on the box, not just the app you were looking at. On a server running several apps, restarting one from its own row is almost always what you want instead.
Save the process list
Save list writes the current set of processes to PM2's saved process list, the same thing pm2 save does. PM2 restores that list when the server reboots.
Click it after you add or remove a process. If you never save, a reboot brings back whatever was saved last, which may not match what is running now.
Inspect one process
Click any row and a detail panel opens on the right. The header shows the process name and status, along with its id, pid, mode, and how long it has been up.
The same actions are repeated at the top of the panel as full buttons - Restart, Reload, Stop, and delete - so you do not have to close the panel to act on what you are looking at. Under them sit quick chips for CPU, memory, and restart count.
The panel has two tabs: Overview and Logs.
Overview tab
Six cards across the top, each with a live sparkline so you can see the trend rather than just the current number:
| Metric | Why it matters |
|---|---|
| CPU | Sustained high CPU on a Node process usually means a blocking loop, not real work. |
| Memory | Resident memory. A number that only ever climbs is the classic leak signature. |
| Event loop lag | How long the event loop is delayed. This is the number that actually predicts slow responses. |
| Heap usage | How full the V8 heap is as a percentage. Near 100% and climbing means a crash is coming. |
| Restarts | How many times PM2 has had to bring this process back. |
| Uptime | How long it has been up since the last restart. |
Event loop lag is the metric worth learning. CPU and memory tell you the process is busy; event loop lag tells you it has stopped being responsive. A healthy Node process sits under a millisecond. Once lag climbs into the hundreds, requests are queueing behind synchronous work even though CPU may look fine.
Below the cards, Node.js runtime reports what the process looks like from inside V8, with the Node version it is running on:
- Active handles and active requests - open sockets, timers, and file operations the process is holding.
- Heap size, used heap size, and heap usage - how much memory V8 has claimed and how much of it is actually in use.
- Event loop latency and event loop latency p95 - the typical delay, and the delay at the bad tail. The p95 is the one your slowest users feel.
Then Auto-restart rules shows the conditions PM2 will act on for this process:
- Max memory restart - the memory ceiling that triggers an automatic restart, or
not set. - Watch & reload - whether PM2 restarts the process when its files change.
- Autorestart - whether PM2 brings it back when it exits.
- Last exit code - how it ended last time.
0is a clean exit; anything else is a crash worth reading the logs for.
Logs tab
Switch to Logs and that single process's output streams in live. A streaming indicator confirms the feed is running.
This is scoped to the one process you opened, which is the difference between it and the Logs tab. Here you are watching one app's output as it happens. There you are reading whole log files on disk, with history, download, and search across everything on the server.
- Filter log lines narrows the stream to what you are looking for as it arrives.
- Flush clears the view so the next lines land against a clean screen. Useful right before you reproduce a bug.
Reproducing something intermittent? Open the process, switch to Logs, click Flush, then trigger the behaviour. Whatever appears is entirely from your attempt, with no scrollback to wade through.
Manage a cluster
An app running in cluster mode appears as a single row with its instance count under the name, for example 4 instances · index.js, and cluster ×4 in the Mode column. The CPU and memory on that row are the totals across every instance.
Click the chevron at the left of the row to expand it. Each instance is then listed on its own line with its own PM2 id, status, CPU, memory, and restart count, plus its own restart and stop buttons and an arrow to open its detail panel.
That split matters when only one worker is misbehaving. Instead of reloading the whole cluster, expand it, find the instance eating memory or racking up restarts, and restart just that one.
The parent row keeps its own controls, so you can still act on the cluster as a whole, and carries an extra settings button for cluster-level configuration.
Use reload rather than restart on a cluster. PM2 replaces the instances one at a time and the remaining workers keep serving requests, so the app never goes dark.
Tips
Read the restart column before anything else. A process with a three-digit restart count has been crash-looping, and PM2 has been quietly papering over it. That is where your problem is, even if the status currently says ONLINE.
Deployed an app through Deployments and it will not come up? It is already here under its deployment name. Open it and go straight to the Logs tab - the reason is almost always in the last few lines.
Changed environment variables in the File Manager? The app will not pick them up on its own. Come back here and click restart on that process instead of running pm2 restart in a terminal.
Troubleshooting
Frequently Asked Questions
How do I manage PM2 processes without the command line?
Open CtrlOps, click your server, and go to the PM2 tab. Every process PM2 keeps alive on that server is listed with its status, mode, CPU, memory, and restart count. Each row has buttons for restart, reload, start or stop, and delete, so every action is a single click instead of a pm2 command typed into a shell.
What is the difference between restart and reload in PM2?
Restart kills the process and starts it again, so there is a short window where it serves nothing. Reload replaces workers one at a time and keeps serving requests throughout, which is why it is called a zero-downtime restart. Reload only truly avoids downtime in cluster mode - on a fork ×1 process it behaves much like a restart.
Can I restart all my PM2 processes at once?
Yes. Click the green Restart all button at the top right of the PM2 tab. It restarts every process PM2 is managing on that server, the equivalent of pm2 restart all. It affects everything on the box, so use it when you mean the whole server, not one app.
How do I see how much CPU and memory a PM2 process is using?
The process list shows live CPU and memory for every process, and the summary cards at the top add up total CPU and total memory across all of them. Click any process to open its detail panel, where CPU, memory, event loop lag, heap usage, restarts, and uptime each get their own card with a live sparkline.
Can I view PM2 logs for a single process live?
Yes. Click a process, then open the Logs tab in its detail panel. Lines stream in as the process writes them and a streaming indicator confirms the feed is live. You can filter the lines with the search box, and Flush clears what is on screen so the next lines arrive against a clean view.
Does CtrlOps work with PM2 cluster mode?
Yes. A clustered app appears as a single row showing the instance count and combined CPU and memory. Expand it with the chevron and every instance is listed separately with its own id, CPU, memory, and restart controls. You can act on one misbehaving instance or on the whole cluster from the parent row.
What does Save list do?
Save list writes the current set of running processes to PM2's saved process list, the same thing pm2 save does. PM2 restores that saved list when the server reboots, so anything you started or deleted survives a restart. Without saving, a reboot brings back whatever was saved last.
Application Deployment
Connect your GitHub account, pick a repo and branch, and deploy Node.js, React, or Next.js apps to your Linux server. No CI/CD setup required.
Log Management
The Logs module scans your Linux server, finds every log file on it, and groups them for you - Nginx access and error logs, PM2 process logs, whatever else is running. Open one, search it, tail it live, download it, or clear it. No SSH session, no hunting for file paths, no manual tail or grep.