Quickstart notes
Keep the Node.js drop listener running with pm2
The Node drops listener is a long-lived process, and long-lived processes die. pm2 restarts them, rotates their logs, and starts them on boot.
The Node.js quickstart's drop listener is a long-lived process, and long-lived processes die: the VPS reboots, the process crashes, the deploy wipes it. A browser tab or a screen session is not the answer for something you rely on. pm2, the small process manager for Node, is: it restarts the listener on crash, starts it on boot, and keeps its logs tidy.
The listener, supervised
The quickstart's listener holds one connection open to the drop stream and reads it forever, as the Node.js page sets it up. Under pm2, the same script becomes a managed service:
pm2 start listen.js -n drops
pm2 save
pm2 startup
The first line starts the script under supervision, the second remembers it, the third hooks it into the system boot. A crash now means a restart in seconds, not a dead feed until someone notices.
What the restart covers, and what it does not
pm2 restarts the process when it exits, which covers crashes, memory kills and reboots. It does not fix a stream that went quiet: a connection that stays open but says nothing needs the listener's own reconnect logic, which the quickstart builds in. The two layers work together: the listener handles a dead connection, pm2 handles a dead process.
Set a restart delay so a crash loop does not hammer the stream endpoint: a listener that reconnects in a tight loop is a problem for the stream, and pm2's restart delay option spaces the retries.
Logs without the babysitting
The listener's console output becomes the diagnostic record, and pm2 writes it to rotating files instead of a terminal you closed last week. One line per alert batch and one per reconnect is enough; the drop stream behaves, control messages included, which the Python page documents; it is the reference when the log shows something odd.
pm2 logs drops
tails the record live when you want to watch it, and leaves it alone when you do not.
When you outgrow one process
pm2 can run the same script twice for two machines, but the drop stream holds one connection per key, so a second live listener with the same key closes the first. Redundancy on this stream means a standby on another host, not a cluster on one. For a single reader, though, pm2 plus the reconnect logic is the whole reliability story.
Start it once, save it, hook it to boot. The listener keeps listening, and the weekend stops being a risk.