starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Response Time graph doesn't bring correct time frame when selecting 24h #4398

New issue

Open

opened 2026-02-28 04:01:09 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-28 04:01:09 -05:00

Owner

Originally created by @jcasarini on GitHub (Oct 31, 2025).

Couldn't find any.

🛡️ Security Policy

I have read and agree to Uptime Kuma's Security Policy.

📝 Description

When selecting 24h in the Response Time graph, it only brings the last 12 hours.

👟 Reproduction steps

Clic on a monitor
Use the dropdown menu to select 24h in the Response Time graph.

👀 Expected behavior

The Time Response graph should show 24 hours of historical response time data.

On a side note, is there anyway to show more than a week's worth of data?

😓 Actual Behavior

The Time Responde graph only shows 12 hours of historical response time data.

🐻 Uptime-Kuma Version

2.0.2

💻 Operating System and Arch

Ubuntu 24.04 LTS

🌐 Browser

Google Chrome Stable

🖥️ Deployment Environment

Runtime Environment:
- Docker: Version 28.1.1
- Docker Compose: Version 2.35.1
Database:
- MariaDB: Embedded
Database Storage:
- Filesystem:
  - Linux: ext4
- Storage Medium: HDD RAID5
Uptime Kuma Setup:
- Number of monitors: 125

📝 Relevant log output

Originally created by @jcasarini on GitHub (Oct 31, 2025). ### 📑 I have found these related issues/pull requests Couldn't find any. ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description When selecting 24h in the Response Time graph, it only brings the last 12 hours. ### 👟 Reproduction steps - Clic on a monitor - Use the dropdown menu to select 24h in the Response Time graph. ### 👀 Expected behavior The Time Response graph should show 24 hours of historical response time data. On a side note, is there anyway to show more than a week's worth of data? ### 😓 Actual Behavior The Time Responde graph only shows 12 hours of historical response time data. <img width="1254" height="359" alt="Image" src="https://github.com/user-attachments/assets/50fb96c0-aa19-4387-a336-fef1b0d24815" /> ### 🐻 Uptime-Kuma Version 2.0.2 ### 💻 Operating System and Arch Ubuntu 24.04 LTS ### 🌐 Browser Google Chrome Stable ### 🖥️ Deployment Environment - **Runtime Environment**: - Docker: Version `28.1.1` - Docker Compose: Version `2.35.1` - **Database**: - MariaDB: Embedded - **Database Storage**: - **Filesystem**: - Linux: ext4 - **Storage Medium**: HDD RAID5 - **Uptime Kuma Setup**: - Number of monitors: `125` ### 📝 Relevant log output ```bash session ```

deekerman added the

bug

cannot-reproduce

labels

2026-02-28 04:01:09 -05:00

deekerman commented

2026-02-28 04:01:14 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Oct 31, 2025):

On a side note, is there anyway to show more than a week's worth of data?

Please see the following issue for context what would need to be tested/contributed:

https://github.com/louislam/uptime-kuma/issues/2477

@CommanderStorm commented on GitHub (Oct 31, 2025): > On a side note, is there anyway to show more than a week's worth of data? Please see the following issue for context what would need to be tested/contributed: - https://github.com/louislam/uptime-kuma/issues/2477

deekerman commented

2026-02-28 04:01:15 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 30, 2025):

Maybe related to

#6547

Just as in that isssue, I don't know what is happening (-> as said in another duplicated of this issue, not reproducible).
A sql backup of the db would help, but would be a lot of work for you to prepare (+ensure that it does not include any secrets).
Currently, this issue is not very actionable as I don't have a testcase/ state to start debugging from.

@CommanderStorm commented on GitHub (Dec 30, 2025): Maybe related to - #6547 Just as in that isssue, I don't know what is happening (-> as said in another duplicated of this issue, not reproducible). A sql backup of the db would help, but would be a lot of work for you to prepare (+ensure that it does not include any secrets). Currently, this issue is not very actionable as I don't have a testcase/ state to start debugging from.