PM2 Process Manager

Every PM2 process. Managed by clicking.

In pm2 list, a process that has restarted 120 times looks exactly like a healthy one. CtrlOps makes it obvious, shows you why, and restarts, reloads or stops it in one click.

Start Free TrialRead the docs
How It Works

How it works

Step 01 - CtrlOps

Lists.

Open the PM2 tab and every process the daemon is keeping alive is there, with live CPU, memory and restart counts.

Step 02 - It

Shows.

Open one and you get event loop lag, heap usage and the auto-restart rules it is running under - plus its logs, live.

Step 03 - You

Act.

Restart, reload without dropping requests, stop, or delete. One click each, no command to remember.

Apple SiliconBest
Apple Intel
Windows
Same Server, Two Ways

Did the restart work? Run pm2 list again to find out.

A terminal answers one question at a time and never volunteers the next one. What is running, what is wrong with it, why - then you re-run the command you started with, because that is the only way to see whether the fix took.

Managing PM2 from a terminal compared with the CtrlOps PM2 tab
Every control in the PM2 tab, and the command it replaces
Go on, drive it

This is the PM2 tab. Nothing here is a video.

A working replica of the panel, with the same guards the real one has. Start where a fresh server starts: with no pm2 binary at all.

Interactive PM2 process manager demo
ctrlops - pm2 · root@203.0.113.17

PM2 is not installed

No pm2 binary was found on this server. Install it globally to manage processes from here.

PM2 needs Node.js on the server. This one has v22.

There is no Create Process button here because the tab does not have one - it manages what PM2 already knows about. There are no alerts and no metric history either, for the same reason.

Sorted by restartsnot by status
checkout-apierrored↺ 120
mail-relayonline↺ 30
storefrontonline↺ 2
queue-workeronline↺ 1

Every one of these except the first says online. Only one of them is actually fine.

↺ under 10

Normal. Deploys and the odd blip.

↺ 10 to 99

Worth a look. Something is knocking it over.

↺ 100+

Crash-looping. PM2 is papering over a real bug.

The column nobody reads

Online is not the same as healthy.

PM2 does its job so well that it hides the problem. A process crashes, PM2 brings it back, and the status column says online again within a second. Do that thirty times an hour and the status column still says online.

The restart count is the only place that shows up, and in pm2 list it is one more column of digits in a monospace table. Here it is colour-coded, so a three-digit history is the loudest thing on the screen instead of the quietest.

That is the whole trick: sort your attention by restarts, not by status. A process that has come back 120 times is where your bug is, whatever colour its dot is right now.

Inside the tab

The numbers pm2 list never showed you.

Live metrics per process, the runtime internals underneath them, and the controls that act on what you find - plus the two caveats worth knowing before you click.

The metric that predicts slow

CPU and memory tell you a process is busy. Event loop lag tells you it has stopped answering. A healthy Node process sits under a millisecond; once lag climbs into the hundreds, requests are queueing behind synchronous work even though CPU looks fine.

One worker, not the whole cluster

A clustered app is one row with its combined CPU and memory. Expand it and every instance has its own id, memory and restart count - so when one worker is leaking, you restart that one and leave the other three serving.

This app's output, not the whole box

Open a process and its output streams into the panel, filtered to that one app. For whole log files with history, the Logs tab is still where you go.

What PM2 will do without you

Max memory restart, watch and reload, autorestart, and the last exit code, per process. Worth knowing: reload is only zero-downtime in cluster mode - on a fork process there is one worker, so it behaves like a restart.

No pm2 on the box yet?

The tab says so and offers to install it globally, so a fresh server goes from nothing to a managed process list without you opening a shell. Node.js needs to be there first.

What this is, and is not

A control panel, not a monitoring platform.

This is the honest version of the boundary. The PM2 tab is where you act on processes - see what is wrong and fix it while you are sitting there. It is not where you find out that something broke overnight, and it never claims to be.

What it does

  • Lists every process PM2 is managing, with live CPU, memory and restart counts.
  • Restarts, reloads, starts, stops and deletes them - one click each.
  • Shows event loop lag, heap usage and Node.js runtime internals per process.
  • Streams a single process's logs live, filtered as they arrive.
  • Expands a cluster so you can act on a single instance.
  • Installs PM2 on a server that does not have it.

What it does not

  • No alertingNothing pages you, emails you or posts to Slack when a process dies. The tab shows you what is happening while you are looking at it. If you need to know at 3am, use PM2 Plus, Datadog, or Prometheus with Alertmanager.
  • No metric historyThe cards and sparklines are live only. Nothing is retained, so there is no last Tuesday to compare against and no trend over a week. That is an APM's job. This replaces pm2 monit, not your monitoring stack.
  • No process authoringYou cannot create a process or edit ecosystem.config.js from the tab. It manages what PM2 already knows about. Apps shipped through CtrlOps deployments register themselves; anything else you start once, then manage here.

It runs over the SSH connection you already have, so nothing is installed on the server beyond PM2 itself and nothing about your processes leaves your machine. See how CtrlOps handles SSH, or the PM2 documentation for every control in detail.

PM2 FAQ

Questions before the next restart.

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. The PM2 documentation walks through each control.
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, where PM2 has other instances to carry the traffic. On a fork mode process there is a single worker, so reload behaves much like a restart.
Yes, and the restart count is usually what tells you first. A process sitting at 120 restarts has been crash-looping even if its status currently reads ONLINE. Click it and open the Logs tab in its detail panel to watch its output stream live. The reason is almost always in the last lines before each restart - commonly a missing environment variable, a port already in use, or a database it cannot reach.
Yes. A clustered app appears as a single row showing the instance count and the combined CPU and memory. Expand it with the chevron and every instance is listed separately with its own id, CPU, memory, and restart count, plus its own restart and stop controls. That matters when one worker is misbehaving - you can restart just that instance instead of reloading the whole cluster.
The same facts, arranged so you can act on them. Live CPU and memory per process rather than a snapshot, totals for online, errored and stopped across the whole server, and a colour-coded restart count so crash-looping is visible instead of being one more column of digits. Open a process and you also get event loop lag, heap usage, Node.js runtime internals like active handles and event loop latency p95, and the auto-restart rules it is running under.
No. There are no alerts, no notifications, and no integrations with PagerDuty, Slack, or email. The PM2 tab shows you what is happening while you are looking at it. If you need to be told at 3am that a process died, you need a monitoring platform with alerting - PM2 Plus, Datadog, or a self-hosted Prometheus and Alertmanager. This tab is for when you are already at your desk and something needs fixing now.
No. The metric cards and their sparklines are live only - they show what is happening now and the last few moments of trend, and nothing is stored. You cannot look back at what memory did last Tuesday or compare this week against last. If you need retained metrics and time-series history, that is an APM, and PM2 Plus, Datadog, or New Relic do it properly. What this replaces is pm2 monit, not your monitoring stack. For live server-wide CPU and memory, see infrastructure monitoring.
No. The PM2 tab manages processes PM2 already knows about - it does not start new ones and it does not edit ecosystem config files. Apps shipped through CtrlOps deployments are registered with PM2 as part of the deploy, so they appear here automatically. Anything else you start yourself, from a shell or an ecosystem file, and then manage from here.
Get started

Stop typing pm2 restart.

Connect a server and every PM2 process on it is listed in seconds, with live CPU, memory and logs. Restart, reload or scale any of them in one click. 1-month free trial, no credit card.

✓ Start instantly·✓ No credit card·✓ No sneaky autorenewals