Uptime tracking shows incorrect data after fresh deployment (1.18.x EE)

[virtneu]

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

[AstralDestiny]

Are all bars shown with no downtime? Got an image by chance?

[virtneu]

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.

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]

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]

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]

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.

[virtneu]

[AstralDestiny]

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]

[virtneu]

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.

[AstralDestiny]

Yep notifying.