mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-07 05:09:18 -05:00
[GH-ISSUE #3007] Uptime tracking shows incorrect data after fresh deployment (1.18.x EE) #11057
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#11057
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @virtneu on GitHub (May 5, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3007
Originally assigned to: @oschwartz10612 on GitHub.
Describe the Bug
Three related issues with the uptime tracking feature introduced in 1.18.0:
Issue 1 —
no_datadays rendered as healthy barsThe API returns
status: "no_data"for all days before deployment (Apr 5 – May 3), but the UI renders them as filled green bars instead of grey/empty. This makes a 2-day-old instance appear to have 30 days of uptime history.Issue 2 — Uptime tracker stops recording after deployment day
The API response shows the last recorded entry is May 4 (deployment date). A downtime event that occurred on May 6 is completely absent from the data, indicating the backend has stopped writing new uptime records after the initial deployment.
Issue 3 — Tooltip date is frozen at deployment date
The date shown in the uptime bar tooltip is stuck at May 4 and does not update to reflect newer events.
Environment
To Reproduce
Expected Behavior
status: "no_data"(before deployment) should be rendered as grey/empty bars, not green filled bars@AstralDestiny commented on GitHub (May 6, 2026):
Are all bars shown with no downtime? Got an image by chance?
@virtneu commented on GitHub (May 6, 2026):
The displayed date drifts over time as the cache expires and is recomputed. The date shown changed from May 4 → May 5 within a few hours without any new events, confirming the date is not anchored to a calendar day but is a rolling window artifact.
await cache_default2.set(cacheKey, result, STATUS_HISTORY_CACHE_TTL);
const dayStartSec = nowSec - (days - d) * 86400;
const dateStr = new Date(dayStartSec * 1e3).toISOString().slice(0, 10);
@AstralDestiny commented on GitHub (May 6, 2026):
Not sure I see the issue in the image If you highlight over it should be set to current day and then the last 30 days, So it'll eventually fill up it wouldn't make much sense if the uptime fills the full bar?
@AstralDestiny commented on GitHub (May 6, 2026):
But I don't see an issue as it's showing last 30 days sure it hasn't been 30 days but still not seeing an issue myself.
Middle one is I've removed the healthcheck for a resource. It's a resource I just update often to test issues or odd things others are having.
@virtneu commented on GitHub (May 6, 2026):
It's probably a time zone issue.My timezone is UTC+8, and it should be showing May 6th, but it's only showing May 5th.
@virtneu commented on GitHub (May 6, 2026):
@AstralDestiny commented on GitHub (May 6, 2026):
Yep mine is showing may 5th right now likely being locked to server time or defaulting to UTC.
Though it's 6th right now and I'm either UTC-4 or UTC-5 right now I haven't checked if we shifted.
@AstralDestiny commented on GitHub (May 6, 2026):
@virtneu commented on GitHub (May 6, 2026):
It would be best to convert the user's time zone here, or explicitly specify that it is UTC.
@AstralDestiny commented on GitHub (May 6, 2026):
Yep notifying.