The activity log (#145) gives fork-observer a persistent, timestamped, per-node stream of classified events — tip changes, reorgs (with depth and common ancestor), tips added, invalid blocks observed, node unreachable/reachable, version changes, and lagging/caught-up transitions. So far this data is only displayed (the activity list and playback pages). But monitoring data nobody is actively watching is worth little: the natural next step is to push notable events out so operators hear about them without staring at a screen.
The activity log is exactly what enables this. Events are already classified by kind and carry structured details, and they flow through a single writer task as they're persisted — the ideal hook point. A notification layer is then mostly plumbing on top: as events are written, match them against a per-network / per-kind / per-node configuration and dispatch.
Concretely, I'd propose generic webhooks — a configurable HTTP POST (Discord, Slack, Matrix, or a plain endpoint) carrying the event's kind, details, node, network, and timestamp — with config to select which kinds fire for which nodes, so an operator can say e.g. "ping me on reorg-detected and invalid-block-observed, but not on every tip change." Delivery should be best-effort and non-blocking so a slow or down webhook endpoint never stalls the writer.
On the RSS side, fork-observer already serves forks.xml, invalid.xml, lagging.xml, and unreachable.xml, but rss.rs recomputes them from the current cache state on each request and even carries its own lagging threshold, duplicating logic the activity log now owns properly. This is a good opportunity to fold those feeds onto the activity log as the single source of truth (dropping the duplicated threshold) and add a combined activity.xml. That gives a consistent, historical, paginatable feed for free and keeps the alerting definition in one place.
The activity log (#145) gives fork-observer a persistent, timestamped, per-node stream of classified events — tip changes, reorgs (with depth and common ancestor), tips added, invalid blocks observed, node unreachable/reachable, version changes, and lagging/caught-up transitions. So far this data is only displayed (the activity list and playback pages). But monitoring data nobody is actively watching is worth little: the natural next step is to push notable events out so operators hear about them without staring at a screen.
The activity log is exactly what enables this. Events are already classified by
kindand carry structureddetails, and they flow through a single writer task as they're persisted — the ideal hook point. A notification layer is then mostly plumbing on top: as events are written, match them against a per-network / per-kind / per-node configuration and dispatch.Concretely, I'd propose generic webhooks — a configurable HTTP POST (Discord, Slack, Matrix, or a plain endpoint) carrying the event's kind, details, node, network, and timestamp — with config to select which kinds fire for which nodes, so an operator can say e.g. "ping me on reorg-detected and invalid-block-observed, but not on every tip change." Delivery should be best-effort and non-blocking so a slow or down webhook endpoint never stalls the writer.
On the RSS side, fork-observer already serves
forks.xml,invalid.xml,lagging.xml, andunreachable.xml, butrss.rsrecomputes them from the current cache state on each request and even carries its own lagging threshold, duplicating logic the activity log now owns properly. This is a good opportunity to fold those feeds onto the activity log as the single source of truth (dropping the duplicated threshold) and add a combinedactivity.xml. That gives a consistent, historical, paginatable feed for free and keeps the alerting definition in one place.