pm2.keymetrics.io

What is PM2?

PM2 is a production process manager for Node.js. It runs your app as a background daemon, restarts it if it crashes, and keeps it online without you babysitting a terminal. Install it globally with npm install pm2 -g, then start an app with pm2 start app.js.

Beyond simple supervision, PM2 covers the operational chores that show up once a Node.js service has real users:

• Cluster mode and a built-in load balancer — run multiple instances of your app across CPU cores.
• Zero-downtime reloads and hot reload — deploy new code without dropping requests.
• Startup scripts — bring your processes back after a server reboot.
• Log management, watch-and-reload, and max-memory restart — cap runaway memory use and react to file changes in development.
• Deployment workflow and container integration — fit PM2 into existing pipelines.

The project also offers a separate monitoring dashboard for tracking bugs, exceptions and alerts, plus an AI assistant that connects MCP-compatible tools to your monitoring data. Those are distinct products from the open-source process manager, so don't assume they come bundled.

Who it's for

A solo developer running one Node.js API on a VPS gets crash recovery and reboot persistence with almost no setup. A team running several services on one box gets cluster mode and centralized logs. The trade-off is that PM2 is Node.js-specific; if your stack is Python, Go or Ruby, look at systemd, Supervisor or your platform's own process handling instead. In containerized environments, Kubernetes or your orchestrator often already provides restart and scaling, so PM2's value shifts toward in-process clustering and log handling rather than supervision.

Next step

Install it and run pm2 start app.js, then pm2 list to confirm the process is managed. If you want to compare supervision approaches before committing, see PM2 for the official feature list and documentation.

How do I install PM2 globally with npm?

Run this one command on the machine where your Node.js app will live:

npm install pm2 -g

The -g flag installs PM2 globally, so the pm2 command becomes available system-wide rather than only inside one project folder. You need Node.js and npm already installed; PM2 itself does not bundle them.

If the install fails with a permission error, that is npm trying to write to a system directory as a normal user. Two common fixes:

• Use a Node version manager such as nvm, which installs global packages into your home directory and avoids sudo entirely.
• Or prefix the command with sudo — acceptable on a throwaway server, less so on a shared one.

Once installed, confirm it works with pm2 --version, then start your app:

pm2 start app.js

To keep apps running across reboots, PM2 generates a startup script for your init system:

pm2 startup
pm2 save

pm2 startup prints a command you must run yourself (usually with elevated privileges); pm2 save records the current process list so it is restored on boot. Skipping pm2 save is the most common reason apps vanish after a restart.

What you get beyond a plain install

The global install is the entry point to the rest of the toolset. From there you can add cluster mode for multi-core use, watch-and-reload during development, log management, and memory-based restarts. PM2's own page lists these as part of its production feature set, including a built-in load balancer and zero-downtime reloads.

Monitoring is a separate layer. Connecting the process manager to the hosted dashboard uses:

pm2 monitor

That links the local daemon to a web-based view of exceptions, metrics and alerts. The page also describes an MCP endpoint for querying server status, logs and exceptions through an AI assistant, and an enterprise offering handled by direct contact rather than self-serve signup. Treat those as optional add-ons: the global install and pm2 save are what actually keep a small app online.

A practical decision point

If you are deploying to a single VPS and just want your process to survive crashes and reboots, the global npm install plus pm2 startup and pm2 save is enough. If you are already running Kubernetes or a platform that restarts containers for you, PM2 duplicates work you have already paid for — check what your platform provides before adding another supervisor.

Next step: after pm2 start app.js, run pm2 logs to confirm your app is actually producing output, and pm2 list to see its status and restart count.

How does PM2's cluster mode and built-in load balancer work for keeping a Node.js app online 24/7?

PM2's cluster mode runs your Node.js app as multiple worker processes behind a built-in load balancer, so one crashing worker does not take the whole app down. The load balancer distributes incoming connections across those workers, and PM2 restarts any worker that exits. Combined with startup scripts that relaunch PM2 after a server reboot, this is how the tool aims to keep an app online around the clock.

How the pieces fit together

• Cluster mode: PM2 spawns several instances of your entry file (for example, one per CPU core) and shares the same port across them.
• Built-in load balancer: Rather than a separate reverse proxy, PM2's daemon accepts connections and routes them to a free worker, so you do not configure Nginx or HAProxy just for distribution.
• Process supervision: If a worker crashes, PM2 restarts it; the other workers keep serving traffic in the meantime.
• Zero-downtime reloads: pm2 reload replaces workers one at a time instead of stopping the whole app, so deploys do not create an outage window.
• Max memory reload: PM2 can restart a worker that exceeds a memory threshold, which limits the blast radius of a leak.
• Startup scripts: pm2 startup plus pm2 save regenerates the process list after a machine reboot.

A concrete scenario

Suppose a single-process Express API occasionally throws an unhandled exception under load. Running it with pm2 start app.js -i max turns it into several workers. A crash in one worker triggers a restart, while the others continue answering requests. During a deploy, pm2 reload app.js cycles workers gradually, so users see no connection failures. If the app leaks memory, the max-memory setting can recycle the offending worker before the whole process becomes unresponsive.

Trade-offs to weigh

Next step

Decide based on your app's statefulness. If it keeps sessions or local caches in process memory, either externalize that state first or run a single instance and rely on PM2 mainly for restarts and startup scripts. If it is stateless, cluster mode with -i max is the straightforward choice. For visibility into restarts, memory and exceptions, the project also offers a monitoring dashboard via PM2 and an AI assistant that queries the same monitoring data.

How do I set up PM2 to automatically start my Node.js applications after a server reboot?

Use PM2's startup-script feature: run your app under PM2, save the current process list, then generate and install a boot script for your init system. PM2 ships pm2 startup, which prints (and, with the right privileges, executes) the command your OS needs to relaunch the PM2 daemon at boot; pm2 save snapshots the running process list so the daemon resurrects exactly those apps.

Typical sequence

npm install pm2 -g          # install PM2 globally
pm2 start app.js --name web-api   # start your app(s)
pm2 save                    # snapshot the current process list
pm2 startup                 # print/install the boot script
# run the command it prints (often with sudo), then:
pm2 save                    # re-save after any later changes

Notes that matter in practice:

• Order counts. Save after you have started every app you want back, and re-run pm2 save whenever you add, remove or rename a process. Otherwise the reboot restores a stale list.
• pm2 startup may need elevation. It detects systemd, upstart, launchd or another init system and emits a command tailored to it; on many hosts you must run that emitted command as root. If you skip this step, the daemon never comes back.
• Cluster mode changes the picture. With pm2 start app.js -i max, PM2's built-in load balancer forks multiple workers; the saved list records that configuration, so the same instance count returns after reboot. Confirm your app is stateless or uses shared sessions before relying on this.
• Memory limits interact with restarts. PM2's max-memory-reload can restart a process automatically; if you also want to know why, the monitoring side is relevant. As one PM2 user, Adam Robinson, put it, installing PM2 and hooking it up to Keymetrics felt "seamless." In practice, a restart at 3 a.m. is exactly the case where post-reboot uptime alone is not enough — you want the reason logged.

When the basic setup is not enough

A useful decision criterion: if a reboot is the only failure you care about, the two commands above are the whole job. If you also care about why processes die, add monitoring before you add complexity elsewhere — the boot script restores state, it does not explain it. Next step: run pm2 startup, copy the exact command it prints, execute it, then reboot once deliberately to verify your apps return.

How do I connect an AI assistant like Claude or Cursor to my PM2 monitoring data via MCP?

Connect your AI assistant to PM2's MCP endpoint, then authenticate with your PM2.io account so the assistant can query your live monitoring data.

Steps

1. Install and run PM2 on the server you want to monitor, then link it to PM2.io with pm2 monitor (as shown in PM2's own docs) so data is flowing to your account.
2. In your AI client (Claude Code, Claude Desktop, Cursor, or any MCP-compatible assistant), add an MCP server entry pointing to: https://mcp.keymetrics.io/mcp
3. Complete the OAuth sign-in with your PM2.io account when prompted. Access is scoped to that account, so the assistant sees your servers, not everyone's.
4. Test with a question phrased around your actual data, e.g. "Why did web-api restart last night?" or "Which process used the most memory in the last 6 hours?"

What you can ask about PM2 lists 44 AI tools across these data types: server status, metrics, logs, exceptions, traces and alerts. A typical exchange looks like: the assistant explains a restart ("web-api restarted at 03:12 after hitting its memory limit"), then offers to create an alert — you confirm, and it sets a rule such as memory > 80% with email notification.

Practical notes

• OAuth means you can revoke access from your PM2.io account if you stop using a given assistant; do that rather than leaving stale connections.
• The assistant is only as good as what PM2 reports. If pm2 monitor isn't linked or a process isn't managed by PM2, there's nothing to query.
• Treat alert creation as a real change to production monitoring: review rules the assistant proposes before approving, especially thresholds that could page you at 3 a.m.
• If you run multiple environments, be explicit in prompts about which app or server you mean, since the assistant may otherwise summarize across all of them.

When this is worth it It suits small teams already running PM2 in production who want faster incident triage without opening a dashboard — asking "what changed before this crash?" in the same tool where you write code. If you don't use PM2 as your process manager, or you can't send monitoring data to an external service, look at alternatives instead, such as Grafana for dashboards or Sentry for exception tracking.

Next step: run pm2 monitor, confirm your apps appear in the PM2 dashboard, then add the MCP endpoint to one assistant and ask a single diagnostic question about a recent restart to verify the connection works end to end.

When should I use the free PM2 process manager versus the paid PM2 Monitoring Dashboard or Enterprise solution?

Use the free PM2 process manager whenever you need to keep Node.js processes running, restart them after crashes, and reload them without downtime. The free tool is the operational core: process management, cluster mode, log handling, startup scripts and deployment workflow. If your need is "keep this app alive and restart it reliably," the free version is enough.

Consider paid options when the question shifts from "is it running?" to "why is it behaving this way, and who needs to know?" The PM2 Monitoring Dashboard adds web-based tracking of bugs, exceptions and alerts. The Enterprise solution targets teams with critical applications that need dedicated infrastructure and advanced optimization.

H3 When the free process manager is the right call

• You run a handful of Node.js services on one or a few servers.
• You are comfortable reading local logs and server metrics yourself.
• Downtime is tolerable for the minutes it takes you to notice and react.
• You want to avoid adding a paid dependency before you have a monitoring need.

H3 When the dashboard starts to pay for itself

• You need alerts when an app crashes or throws exceptions, not just automatic restarts.
• Several people share responsibility for uptime and need one place to look.
• You want historical context: which process restarted, when, and why.
• You are already using the free manager and want visibility layered on top rather than a replacement.

H3 When Enterprise becomes relevant

• The application is business-critical and you need dedicated infrastructure workload.
• You want advanced optimization work rather than self-service tooling.
• Procurement, support commitments and contact-based terms matter to your organization.

A practical decision rule: start free, and move to the dashboard the first time you learn about a failure from a user instead of an alert. That single incident usually costs more than the monitoring would have.

If you use an MCP-compatible AI assistant, the PM2 AI Assistant is a separate product worth knowing about: it connects assistants such as Claude or Cursor to your monitoring data for server status, metrics, logs, exceptions and alerts, authenticated through your PM2.io account. That is most useful once you already have monitoring data worth querying — it does not replace the process manager.

Next step: install the free manager, run your app under it, and note how you currently find out about failures. If the answer is "someone tells me," that is your signal to look at the dashboard. Compare the current options at PM2.