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_data days rendered as healthy bars
The 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
Pangolin version: ee-1.18.2 (Enterprise Edition)
Gerbil version: 1.3.1
Newt version: 1.12.3
Server OS: Ubuntu 24.04 LTS (Noble Numbat)
Deployed: May 4, 2026
To Reproduce
Deploy a fresh Pangolin 1.18.x EE instance
Connect a Newt client to create a site
Navigate to Sites or Resources page
Hover over the 30-day uptime bar
Observe that all 30 bars are filled despite the instance being only 2 days old
Trigger a brief disconnection and reconnect Newt
Check the uptime bar tooltip date — it remains stuck at the deployment date
Expected Behavior
Days with status: "no_data" (before deployment) should be rendered as grey/empty bars, not green filled bars
New downtime events should be recorded in real time and appear in the API response with the correct date
The tooltip date should update to reflect the most recent event, not remain frozen at the deployment date
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_data` days rendered as healthy bars**
The 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
- Pangolin version: ee-1.18.2 (Enterprise Edition)
- Gerbil version: 1.3.1
- Newt version: 1.12.3
- Server OS: Ubuntu 24.04 LTS (Noble Numbat)
- Deployed: May 4, 2026
### To Reproduce
1. Deploy a fresh Pangolin 1.18.x EE instance
2. Connect a Newt client to create a site
3. Navigate to Sites or Resources page
4. Hover over the 30-day uptime bar
5. Observe that all 30 bars are filled despite the instance being only 2 days old
6. Trigger a brief disconnection and reconnect Newt
7. Check the uptime bar tooltip date — it remains stuck at the deployment date
### Expected Behavior
- Days with `status: "no_data"` (before deployment) should be rendered as grey/empty bars, not green filled bars
- New downtime events should be recorded in real time and appear in the API response with the correct date
- The tooltip date should update to reflect the most recent event, not remain frozen at the deployment date
GiteaMirror
added the bug label 2026-06-05 06:29:12 -05:00
Are all bars shown with no downtime? Got an image by chance?
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.
<!-- gh-comment-id:4384402201 -->
@virtneu commented on GitHub (May 6, 2026):
> Are all bars shown with no downtime? Got an image by chance?
<img width="480" height="342" alt="Image" src="https://github.com/user-attachments/assets/f51a20db-1802-479f-957b-e716db848618" />
<img width="724" height="360" alt="Image" src="https://github.com/user-attachments/assets/d2b73c5a-9825-4723-b8a5-c58f5904298a" />
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);
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?
<!-- gh-comment-id:4389379039 -->
@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?
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.
<!-- gh-comment-id:4389392524 -->
@AstralDestiny commented on GitHub (May 6, 2026):
<img width="400" height="675" alt="Image" src="https://github.com/user-attachments/assets/258bff4c-4bc8-4664-becb-97bd22e10b19" />
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.
<img width="568" height="238" alt="Image" src="https://github.com/user-attachments/assets/1813f5f1-7cb9-4c50-b165-97cced8266bd" />
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.
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?
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.
<!-- gh-comment-id:4389448343 -->
@virtneu 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?
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.
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.
<!-- gh-comment-id:4389458005 -->
@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.
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.
It would be best to convert the user's time zone here, or explicitly specify that it is UTC.
<!-- gh-comment-id:4389488788 -->
@virtneu 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.
It would be best to convert the user's time zone here, or explicitly specify that it is UTC.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.