Title
Dashboard metrics never recover after the window is hidden >2 min — heartbeats 404 against swept sessions, values silently freeze until app restart
Platform
Desktop App - Windows
Server Installation Method
Proxmox (Community Scripts)
Version
2.7.1
CLI Installation Method
None
CLI Version
No response
Troubleshooting
The Problem
If the Dashboard is out of sight for more than ~2 minutes — window minimized, or another
tab active — its host metrics never resume updating when it comes back. The cards do not
go blank: they repaint once with the last known values and then freeze silently,
while the client fires a burst of POST /metrics/heartbeat requests that all return
404, roughly one per host, repeating on a timer until the app is restarted. Nothing
surfaces in the UI; the only signs are stale numbers and a red console burst:
Failed to load resource: the server responded with a status of 404 (Not Found)
http://localhost:30005/metrics/heartbeat (x28 per burst on my install)
Captured over the DevTools protocol (29 hosts, 28 with metric sessions — one host has no
reachable metrics endpoint):
- While the window is hidden, all
/metrics/ traffic stops entirely — heartbeats are
suspended, so after 120s the server sweeps the viewer sessions.
- On return, in two separate 3.5–4.5 min observation windows (one per repro path below):
84 heartbeat POSTs, all 404, in 3 bursts of exactly 28, ~90s apart. No
re-registration request is ever sent.
- Dashboard card values refresh once at the moment the tab/window comes back (a one-time
fetch repaints last-known data), then stay bit-for-bit identical for the entire
observation window. When healthy, the same probe shows values changing within ~30s.
- A host's own Host Metrics tab is immune: it stops its session on hide
(POST /metrics/stop/<id>) and starts a fresh one on show (POST /metrics/start/<id>),
after which its heartbeats return 200 and its values keep moving. Only the Dashboard's
register-once-and-heartbeat sessions wedge.
How to Reproduce
- Open the Dashboard, wait for host cards to show CPU/RAM/Disk.
- Minimize the window (or switch to another tab in the app) for more than 2 minutes.
- Return to the Dashboard with the DevTools console open.
Every return after a >2 min gap reproduces it (tested both the minimize path and the
switch-tab path). The cards show plausible but frozen values; the console shows the 404
bursts; only an app restart recovers live updates.
Additional Context
Reading the 2.7.1 sources, the pieces line up with what's on the wire:
- The server sweeps a viewer session after 120s without a heartbeat
(hosts/metrics/index.ts:974).
- The client suspends heartbeats whenever the dashboard is not visible
(DashboardTab.tsx:1483) — consistent with the observed total silence while hidden.
- On becoming visible again it resumes heartbeating the old session IDs and never
re-registers, because registration is guarded by if (!existing)
(DashboardTab.tsx:1363) — consistent with 404s and no registration request ever
appearing.
- The failures are invisible because the heartbeat is fired as
sendMetricsHeartbeat(...).catch(() => {}).
Even switching away to another tab and back — which re-fetches card data once and
repaints — does not re-register the sessions, so the "working-looking" dashboard is
serving stale data on top of a dead session layer. That silent-stale failure mode seems
worse than blank cards: there is no visual hint anything is wrong.
Observed on the Windows desktop app against its embedded backend (metrics service on
localhost:30005); nothing here looks desktop-specific — the sweep/guard logic is shared.
Happy to run anything specific or test a :beta build.
Title
Dashboard metrics never recover after the window is hidden >2 min — heartbeats 404 against swept sessions, values silently freeze until app restart
Platform
Desktop App - Windows
Server Installation Method
Proxmox (Community Scripts)
Version
2.7.1
CLI Installation Method
None
CLI Version
No response
Troubleshooting
The Problem
If the Dashboard is out of sight for more than ~2 minutes — window minimized, or another
tab active — its host metrics never resume updating when it comes back. The cards do not
go blank: they repaint once with the last known values and then freeze silently,
while the client fires a burst of
POST /metrics/heartbeatrequests that all return404, roughly one per host, repeating on a timer until the app is restarted. Nothing
surfaces in the UI; the only signs are stale numbers and a red console burst:
Captured over the DevTools protocol (29 hosts, 28 with metric sessions — one host has no
reachable metrics endpoint):
/metrics/traffic stops entirely — heartbeats aresuspended, so after 120s the server sweeps the viewer sessions.
84 heartbeat POSTs, all 404, in 3 bursts of exactly 28, ~90s apart. No
re-registration request is ever sent.
fetch repaints last-known data), then stay bit-for-bit identical for the entire
observation window. When healthy, the same probe shows values changing within ~30s.
(
POST /metrics/stop/<id>) and starts a fresh one on show (POST /metrics/start/<id>),after which its heartbeats return 200 and its values keep moving. Only the Dashboard's
register-once-and-heartbeat sessions wedge.
How to Reproduce
Every return after a >2 min gap reproduces it (tested both the minimize path and the
switch-tab path). The cards show plausible but frozen values; the console shows the 404
bursts; only an app restart recovers live updates.
Additional Context
Reading the 2.7.1 sources, the pieces line up with what's on the wire:
(
hosts/metrics/index.ts:974).(
DashboardTab.tsx:1483) — consistent with the observed total silence while hidden.re-registers, because registration is guarded by
if (!existing)(
DashboardTab.tsx:1363) — consistent with 404s and no registration request everappearing.
sendMetricsHeartbeat(...).catch(() => {}).Even switching away to another tab and back — which re-fetches card data once and
repaints — does not re-register the sessions, so the "working-looking" dashboard is
serving stale data on top of a dead session layer. That silent-stale failure mode seems
worse than blank cards: there is no visual hint anything is wrong.
Observed on the Windows desktop app against its embedded backend (metrics service on
localhost:30005); nothing here looks desktop-specific — the sweep/guard logic is shared.Happy to run anything specific or test a
:betabuild.