pnclPULSEGet API access

DROP ALERT NOTES

Keep your SSE reader running through the weekend

The stream handles reconnects; the reader process needs its own care. Restart policy, a silence watchdog, state on disk, and an alarm for the reader itself.

The SSE stream reconnects cleanly when the connection drops, but that only covers the wire. The process holding it can die for its own reasons: a deploy, an out-of-memory kill, a host reboot at 4 a.m. on a Saturday. A reader that survives the weekend needs four things: a restart policy, a silence watchdog, state on disk, and an alarm that works when the reader itself is dead.

Plan the restart, not the uptime

Assume the process exits and make the exit cheap. A supervisor that restarts the reader with a growing delay, seconds at first, then minutes, turns a crash into a blip. On startup, resume from what you persisted: the SSE setup guide notes that rule state belongs server-side and that persisting the last processed alert time lets a restart resume cleanly instead of re-alerting on moves you already handled, checked 2026-10-03.

What a restart cannot recover is the gap itself: the documentation promises no resume point, so alerts that fell while you were down are missed. The setup guide's answer is to fill a real gap from the REST drops endpoint, which keeps recent drops for a few hours.

Watch for silence, not just crashes

A reader can be running and receiving nothing. Quiet stretches are normal, prematch especially, so an absence of alerts is not proof of death. The health endpoint settles it: it reports how long ago the live feed last wrote, and the setup guide's rule is to close and reconnect when that age keeps growing while your connection says nothing.

Wire that check into a watchdog that logs its decision. The line saying the stream is silent and the source is silent is what separates a quiet market from a stuck connection at a glance.

Keep the memory on disk

Anything the reader remembers in RAM dies with the process. The dedupe keys, the cooldown windows and the last-alert timestamp belong in a small file or database on disk, written as they change. The dedupe guide covers the store that survives restarts; the weekend version of that advice is that the store should survive a host reboot too.

Alarm for the reader that cannot speak

A dead reader cannot send you an alert about itself. The check has to come from outside: a heartbeat line written every minute, and a separate tiny watcher that pages you when the heartbeat stops during hours with matches. That watcher is a few lines of scheduler and one request, and it is the difference between noticing a dead reader on Friday night and on Monday morning.

Restart cheaply, watch the silence, keep memory on disk, and let something outside the process do the worrying. The stream will do its half.