mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Heartbeat data is returned for longer while editing custom CSS? #3166
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#3166
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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 @TechPhil on GitHub (Mar 4, 2024).
📑 I have found these related issues/pull requests
I have checked and cannot see a similar issue
🛡️ Security Policy
Description
When editing the custom CSS on a status page, I can see that the data on the heartbeat bar(?) is completely filled out.


When I save this CSS, however, only approx. 15 minutes of data is returned
👟 Reproduction steps
Edit Custom CSS
Save Custom CSS
👀 Expected behavior
Data is fully returned to fill all heartbeat bars
😓 Actual Behavior
Data is not fully propagated to heartbeat bars
🐻 Uptime-Kuma Version
1.23.11
💻 Operating System and Arch
Ubuntu 22.01.1 LTS x64
🌐 Browser
Chrome 122.0.6261.95
🖥️ Deployment Environment
📝 Relevant log output
No response
@CommanderStorm commented on GitHub (Mar 4, 2024):
Please see https://github.com/louislam/uptime-kuma/issues/4482
How have you deployed concretely?