Factory Supervisor Pager

TL;DR: A factory had no reliable way for floor operators to page a supervisor when they needed one. I built a small Node.js service on a Raspberry Pi that integrates with the Rogers pager network. It has been in production for over five years without incident. The takeaway: the right minimal solution—constrained to the environment, easy to deploy, and boringly reliable—often beats overbuilt alternatives.

Problem

The factory lacked a dependable way for operators to reach a supervisor. Ad-hoc solutions (yelling, walking to find someone, unreliable phones) didn’t scale and created safety and efficiency gaps. Management needed a simple, always-available “page a supervisor” capability that worked in a noisy industrial environment without requiring new habits or fragile infrastructure.

The constraints were real: no server room, no on-site ops team, and the client already used the Rogers pager network. Whatever I built had to be small, low-power, able to live in a closet, and run unattended for a long time.

The Approach

I put a Raspberry Pi in a cabinet at the site running a small Node.js HTTP service. Operators trigger a page through a simple interface; the service forwards the request to the Rogers paging API. That’s the entire architecture—one Pi, one process, one job.

Everything about this project was a deliberate choice to stay minimal. A Pi instead of a server because the factory didn’t need a server. Node.js because it’s fast to build, easy to reason about, and trivial to run on a Pi. No cloud dependencies because factory networks are often locked down, and keeping the critical path local meant no reliance on internet availability. Stable LTS dependencies and no framework churn because the goal was “run for years without attention,” not “stay current.”

The obvious tradeoff is no redundancy. If the Pi dies, paging is down until someone replaces it. I accepted that because the alternative was no paging system at all, and the requirement was “works day to day” rather than “five nines.” I wrote clear recovery documentation so a replacement could be stood up quickly.

Outcome

Over five years in production without incident. The Pi has stayed up through power cycles and network hiccups, and required no ongoing maintenance beyond being left alone. Not every system needs Kubernetes, cloud, or redundant nodes. When the environment is constrained and the requirement is “reliable and simple,” a single well-chosen node and a focused service can deliver for years.

Technologies

Node.js, Raspberry Pi, HTTP, Rogers paging API, systemd for process management.

Related

• On-Premise Kubernetes Platform — The other extreme: when you need scale and redundancy, the platform is there; this project is an example of when you deliberately don’t
• Architecture Patterns — Right-sizing the solution to the problem and the environment