starred/uptime-kuma

Fork 0

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

Edit status page regression in 2.1 #4712

New issue

Open

opened 2026-02-28 04:12:40 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 04:12:40 -05:00

Owner

Originally created by @hmnd on GitHub (Feb 14, 2026).

🛡️ Security Policy

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

📝 Description

In 2.0, clicking save when editing a status page correctly closed the settings sidebar and applied your settings.

As of 2.1.0-beta.0 (up to and including 2.1.1), clicking save disables the save button permanently, with further changes to the settings not re-enabling the button. Further, when a high number of monitors (>50) are added to the page, the page spikes to 100% CPU usage, causing changes to sometimes not even be saved.

Looking at websocket messages, I see a high number of messages come in specifically when editing the page:
https://github.com/user-attachments/assets/070b58bc-5620-4558-bac5-a9d77ea6dcdb

After hogging the CPU for a little while, I get a bunch of repeated errors logged in console, but they're difficult to make sense of without source maps. Will try to run from source later.

👟 Reproduction steps

Add 50+ monitors to a status page
Edit status page
Click Save
Attempt to make further edit

👀 Expected behavior

Page settings get closed on first Save click
Changes get reliably saved
CPU usage does not spike

😓 Actual Behavior

As described above.

🐻 Uptime-Kuma Version

2.1.1

💻 Operating System and Arch

Docker

🌐 Browser

Google Chrome 144.0.7559.132

🖥️ Deployment Environment

Docker

📝 Relevant log output

Originally created by @hmnd on GitHub (Feb 14, 2026). ### 📑 I have found these related issues/pull requests Possibly related to https://github.com/louislam/uptime-kuma/issues/6888 ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description In 2.0, clicking save when editing a status page correctly closed the settings sidebar and applied your settings. As of 2.1.0-beta.0 (up to and including 2.1.1), clicking save disables the save button permanently, with further changes to the settings not re-enabling the button. Further, when a high number of monitors (>50) are added to the page, the page spikes to 100% CPU usage, causing changes to sometimes not even be saved. Looking at websocket messages, I see a high number of messages come in specifically when editing the page: https://github.com/user-attachments/assets/070b58bc-5620-4558-bac5-a9d77ea6dcdb After hogging the CPU for a little while, I get a bunch of repeated errors logged in console, but they're difficult to make sense of without source maps. Will try to run from source later. ### 👟 Reproduction steps 1. Add 50+ monitors to a status page 2. Edit status page 3. Click Save 4. Attempt to make further edit ### 👀 Expected behavior - Page settings get closed on first Save click - Changes get reliably saved - CPU usage does not spike ### 😓 Actual Behavior As described above. ### 🐻 Uptime-Kuma Version 2.1.1 ### 💻 Operating System and Arch Docker ### 🌐 Browser Google Chrome 144.0.7559.132 ### 🖥️ Deployment Environment Docker ### 📝 Relevant log output ```bash session ```

deekerman added the

bug

label

2026-02-28 04:12:40 -05:00

deekerman commented

2026-02-28 04:12:44 -05:00

Author

Owner

@louislam commented on GitHub (Feb 14, 2026):

Want to make sure I understand correctly.

Is it related to #6888?

the page spikes to 100% CPU usage

Is the cpu usage of your current PC? or server?

As long as you don't click the "Save" button, the cpu usage is normal?

@louislam commented on GitHub (Feb 14, 2026): Want to make sure I understand correctly. Is it related to #6888? > the page spikes to 100% CPU usage Is the cpu usage of your current PC? or server? As long as you don't click the "Save" button, the cpu usage is normal?

deekerman commented

2026-02-28 04:12:45 -05:00

Author

Owner

@romainl63 commented on GitHub (Feb 26, 2026):

Hi,

I'm also having a problem with the status pages, and I'm on version 2.1.3.
I have one with 85 checks, and if I try to modify it, it's incredibly slow, making it practically impossible. Uptime Kuma is running Docker (LXC container on Debian under Proxmox), everything up to date and in the latest versions.

Either the webpage stops responding with an error: (Tested with Firefox and Chrome)
"This page asks you to confirm closing it; data you have entered may not be saved."

If I try to move my probe to another group, it doesn't work either, and sometimes I get an error saying I'm not connected… and the webpage crashes completely.

I'm used to doing this and I'm not doing anything wrong.

I haven't noticed any increase in CPU usage or anything alarming in terms of server performance.

It's been a while since I last modified my status page so I couldn't say from which version it stopped working, but before it was smooth.

@romainl63 commented on GitHub (Feb 26, 2026): Hi, I'm also having a problem with the status pages, and I'm on version 2.1.3. I have one with 85 checks, and if I try to modify it, it's incredibly slow, making it practically impossible. Uptime Kuma is running Docker (LXC container on Debian under Proxmox), everything up to date and in the latest versions. Either the webpage stops responding with an error: (Tested with Firefox and Chrome) "This page asks you to confirm closing it; data you have entered may not be saved." If I try to move my probe to another group, it doesn't work either, and sometimes I get an error saying I'm not connected… and the webpage crashes completely. I'm used to doing this and I'm not doing anything wrong. I haven't noticed any increase in CPU usage or anything alarming in terms of server performance. It's been a while since I last modified my status page so I couldn't say from which version it stopped working, but before it was smooth.

deekerman commented

2026-02-28 04:12:45 -05:00

Author

Owner

@hmnd commented on GitHub (Feb 26, 2026):

@louislam sorry, missed your original reply. It is spiking cpu usage on pc, but I suspected it may related to server, because of a massive number of updates coming over the websocket.

CPU usage rises regardless of the save button.

@hmnd commented on GitHub (Feb 26, 2026): @louislam sorry, missed your original reply. It is spiking cpu usage on pc, but I suspected it may related to server, because of a massive number of updates coming over the websocket. CPU usage rises regardless of the save button.