There is no record of feed outages, so I cannot tell whether the stream dropped overnight #71

New issue

Open

opened 2026-11-03 18:52:35 +00:00 by skippy-bot · 0 comments

skippy-bot commented

2026-11-03 18:52:35 +00:00

Problem

The status page reports the connection state and packet rate as they are right now, from a ten second in-memory cache. When the APRS-IS connection drops at 3am and reconnects, the page looks healthy by morning and nothing anywhere says the feed was down or for how long. A gap in a station's track is indistinguishable from that station being off the air.

Evidence

At 2f150f66:

lib/aprsme_web/live/status_live/index.ex:413 reads a cached snapshot, and :48 shares one snapshot across viewers.
lib/aprsme/connection_monitor.ex keeps its counters in GenServer state and logs load and drain events through Logger, with no table and no telemetry history.
lib/aprsme/is/is.ex tracks reconnect attempts in state, and lib/aprsme/circuit_breaker.ex holds its state the same way, so a restart of either process forgets an outage.

Proposed behavior

The connection state changes are appended to a small table or a Prometheus counter set, with the reason.
The status page shows the last disconnect, its duration, and a 24 hour strip of uptime.
A reconnect after more than a minute notes the gap on the packets timeline.

Why it matters

An operator needs to answer "was the feed down, or was the station quiet" without reading container logs, and today the answer is not stored anywhere.

Acceptance criteria

Connect and disconnect events survive a process restart and are queryable for at least a day.
The status page shows the last outage with its duration.
A test simulates a disconnect and reconnect and asserts the record.

Effort: M
Lens: ops

## Problem The status page reports the connection state and packet rate as they are right now, from a ten second in-memory cache. When the APRS-IS connection drops at 3am and reconnects, the page looks healthy by morning and nothing anywhere says the feed was down or for how long. A gap in a station's track is indistinguishable from that station being off the air. ## Evidence At `2f150f66`: - `lib/aprsme_web/live/status_live/index.ex:413` reads a cached snapshot, and `:48` shares one snapshot across viewers. - `lib/aprsme/connection_monitor.ex` keeps its counters in GenServer state and logs load and drain events through `Logger`, with no table and no telemetry history. - `lib/aprsme/is/is.ex` tracks reconnect attempts in state, and `lib/aprsme/circuit_breaker.ex` holds its state the same way, so a restart of either process forgets an outage. ## Proposed behavior - The connection state changes are appended to a small table or a Prometheus counter set, with the reason. - The status page shows the last disconnect, its duration, and a 24 hour strip of uptime. - A reconnect after more than a minute notes the gap on the packets timeline. ## Why it matters An operator needs to answer "was the feed down, or was the station quiet" without reading container logs, and today the answer is not stored anywhere. ## Acceptance criteria - [ ] Connect and disconnect events survive a process restart and are queryable for at least a day. - [ ] The status page shows the last outage with its duration. - [ ] A test simulates a disconnect and reconnect and asserts the record. **Effort:** M **Lens:** ops

skippy-bot added the

Low

feature

effort: M

labels

2026-11-03 18:52:35 +00:00