Keeping a bot “alive” is not the same as keeping automation healthy. PM2, Supervisor and systemd all start long-running processes and restart them after failure. The right choice depends on runtime and team familiarity, but stability comes from designing the worker lifecycle around failure.
When PM2 fits
PM2 is convenient for Node.js. Its ecosystem file defines commands, instances, environment, memory thresholds and logs. Cluster mode is not automatically safe for bots: multiple instances may consume the same account or task unless queues and locks support concurrency.
When Supervisor fits
Supervisor provides simple, runtime-neutral control for Python, PHP, Node.js and shell commands. Configure a restricted user, working directory, explicit environment, graceful stop signal and log rotation.
When systemd fits
systemd is native to most modern Linux distributions and integrates with boot ordering, users, resource limits, hardening and the journal. Use restart delays and rate limits so a broken release does not create an endless hot loop.
Architecture matters more than the manager
Put tasks in a durable queue, acknowledge them after saving state and make repeated execution safe where possible. Store checkpoints outside process memory. Use bounded retries with backoff and manual review. For third-party platforms, operate within authorized use, published limits and applicable terms; a restart loop must never become an uncontrolled request flood.
Graceful shutdown and deployment
On termination, stop accepting work, finish or safely release the current task, flush logs and close connections. Set a realistic stop timeout. Deploy versioned releases, run a smoke test and retain a documented rollback path.
Common mistakes
- running bots in an SSH session
- using unlimited restarts without delay
- keeping queue state only in memory
- starting duplicate workers for one account
- retrying non-idempotent actions blindly
- running as root
- committing secrets
- letting logs and screenshots fill the disk
- monitoring uptime but not completed work
Practical production checklist
- use a least-privilege service account
- set absolute paths and working directory
- validate environment and secrets at startup
- define restart delay, rate limit and memory ceiling
- handle termination signals
- use durable queues, locks and checkpoints
- make retries bounded and observable
- rotate logs and traces
- alert on stale work, crashes and queue age
- test reboot, network failure and rollback
Monitoring useful work
Track successful tasks, failure categories, duration, queue age, retries and time since the last valid result. Add correlation IDs without recording credentials or unnecessary personal data. See what bot logs should store and how to scale bots safely.
When hiring a technical person makes sense
Bring in an automation or infrastructure engineer when restarts duplicate actions, workers compete for accounts, deployments interrupt jobs, secrets are exposed, or uptime looks good while output stops. Review task semantics, queues, limits, observability and recovery—not only the process manager.
Final takeaway
Choose PM2 for Node convenience, Supervisor for runtime-neutral control or systemd for native Linux services, then design for failure. Explore my automation services or contact me.