🎯 The trap
The admin Health page surfaces Docker's RestartCount as a bare number with no "since when" context. Because RestartCount is monotonic per container object (it never decays — only a container recreation resets it), a restart storm that happened days ago and was long-since fixed keeps showing as, e.g., a red "10" that reads as a current, live problem to anyone glancing at the dashboard.
Dean flagged this on 2026-08-13: genwave-db-1 on the demo box shows restarts=10, all of which occurred in one window on 2026-08-09 (a "no space left on device" crashloop from accumulated dangling images — since fixed by launch.sh's prune check). The container has been up healthy for 4+ days since, but the card still shows 10 with no hint it's historical.
🔧 Fix direction
Pair the count with recency so a frozen historical number can't masquerade as a live incident:
- surface the last-restart timestamp alongside the count ("10 restarts · last 4 days ago"), and/or
- only style it as an alarm when a restart falls within a recent window (e.g. last hour/day); otherwise render it neutral/muted.
The data is already in hand — DockerContainerInspect (src/GenWave.Host/Stats/DockerContainerInspect.cs) already reads State (which carries StartedAt, i.e. when the current container instance started = effectively the last-restart time). Flow to extend: DockerContainerInspect.RestartCount/State → DockerContainerStatsSource.cs:113 → ContainerStatDto (src/GenWave.Host/Api/ContainerStatDto.cs) → the Health page card. Add StartedAt to the DTO and let the card compute recency.
🧪 Ready-made live test fixture
Do not reset the demo box's genwave-db-1 restarts=10 — Dean is deliberately leaving it in place. Once this ships, the card should render that count as clearly historical (last restart 2026-08-09), which is the exact before/after this issue is about. (Resetting it anytime is one safe command: docker compose up -d --force-recreate db — named pgdata volume persists.)
Workstream: Obs+Ops (one of Projects #3–#9). Low severity, high clarity-of-mind payoff.
🎯 The trap
The admin Health page surfaces Docker's
RestartCountas a bare number with no "since when" context. BecauseRestartCountis monotonic per container object (it never decays — only a container recreation resets it), a restart storm that happened days ago and was long-since fixed keeps showing as, e.g., a red "10" that reads as a current, live problem to anyone glancing at the dashboard.Dean flagged this on 2026-08-13:
genwave-db-1on the demo box showsrestarts=10, all of which occurred in one window on 2026-08-09 (a "no space left on device" crashloop from accumulated dangling images — since fixed bylaunch.sh's prune check). The container has been up healthy for 4+ days since, but the card still shows 10 with no hint it's historical.🔧 Fix direction
Pair the count with recency so a frozen historical number can't masquerade as a live incident:
The data is already in hand —
DockerContainerInspect(src/GenWave.Host/Stats/DockerContainerInspect.cs) already readsState(which carriesStartedAt, i.e. when the current container instance started = effectively the last-restart time). Flow to extend:DockerContainerInspect.RestartCount/State→DockerContainerStatsSource.cs:113→ContainerStatDto(src/GenWave.Host/Api/ContainerStatDto.cs) → the Health page card. AddStartedAtto the DTO and let the card compute recency.🧪 Ready-made live test fixture
Do not reset the demo box's
genwave-db-1restarts=10 — Dean is deliberately leaving it in place. Once this ships, the card should render that count as clearly historical (last restart 2026-08-09), which is the exact before/after this issue is about. (Resetting it anytime is one safe command:docker compose up -d --force-recreate db— named pgdata volume persists.)Workstream: Obs+Ops (one of Projects #3–#9). Low severity, high clarity-of-mind payoff.