mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
2.1.0 talking more CPU resources than 2.0 #4682
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#4682
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 @milandzuris on GitHub (Feb 8, 2026).
📑 I have found these related issues/pull requests
.
🛡️ Security Policy
📝 Description
Hi after updating to 2.1.0 my Uptime Kuma after few minutes went from 20% performance (CPU RAM) to 100% performance, before update i dont have any issue same settings i have before update.
👟 Reproduction steps
reboot :D
👀 Expected behavior
.
😓 Actual Behavior
.
🐻 Uptime-Kuma Version
2.1.0
💻 Operating System and Arch
Debian
🌐 Browser
.
🖥️ Deployment Environment
.
📝 Relevant log output
@CommanderStorm commented on GitHub (Feb 8, 2026):
Can you build a reproduciton how to do this?
The logs that you are shared are not much of context
@louislam commented on GitHub (Feb 8, 2026):
In case you have no idea how to reproduce.
We had 4 beta versions in between
2.0and2.1. If possible, please downgrade to the previous version2.1.0-beta.3, see if the problem still persists. Try another version if not. It would help us to identify which version introduced this performance issue.https://github.com/louislam/uptime-kuma/releases/tag/2.1.0-beta.0
https://github.com/louislam/uptime-kuma/releases/tag/2.1.0-beta.1
https://github.com/louislam/uptime-kuma/releases/tag/2.1.0-beta.2
https://github.com/louislam/uptime-kuma/releases/tag/2.1.0-beta.3
Personally, my instance seems fine.
@milandzuris commented on GitHub (Feb 8, 2026):
Before version 2.1.0 i was using version 2.0.2, how can i downgrade on Linux?
@CommanderStorm commented on GitHub (Feb 8, 2026):
we don't support downgrading perse. It might be possible (our mirations all have up + down), but it is not tested.
So the simplest way is to start with a backup and upgrade one beta after another
@milandzuris commented on GitHub (Feb 8, 2026):
So strange now i don't have problem with CPU but with RAM and SWAP
@milandzuris commented on GitHub (Feb 8, 2026):
Very unstable
@milandzuris commented on GitHub (Feb 8, 2026):
i don't see somewhere in settings backup button
@CommanderStorm commented on GitHub (Feb 8, 2026):
We don't currently have a backup button. That feature was removed in v2.0 since it was very broken and unmaintained.
@smhawkes commented on GitHub (Feb 9, 2026):
I have the same issue, I went to beta.0 and seemed ok now running beta.1 and will let it run tonight and check it in the morning.
@hmnd commented on GitHub (Feb 13, 2026):
Also seeing this.
When editing a status page I also see this, paired with very slow client-side performance which is possible related?
Screen recording
@CommanderStorm commented on GitHub (Feb 14, 2026):
since everyone in this thread is sharing the same design of screenshots, might this be related to that?
If not, what is going on inside of the contianer or on the system itsself?
Without being able to reproduce it, there is nothing that I can do
@hmnd commented on GitHub (Feb 14, 2026):
Mine aren't from the same hosting provider as the others. I'm on PikaPods, which runs on Docker. I'll do my best to find a way to repro...
@louislam commented on GitHub (Feb 14, 2026):
Because we have too many changes in between 2.0.2 and 2.1.0, it is honestly hard to identify the root cause.
It would be helpful if you can try older 2.1.0 beta version, and identify which beta version caused this issue.
2.1.0-beta.32.1.0-beta.22.1.0-beta.12.1.0-beta.0Don't forget to backup your data folder before downgrade.
See: https://github.com/louislam/uptime-kuma/issues/6888#issuecomment-3867372272
@hmnd commented on GitHub (Feb 14, 2026):
@louislam I haven't been able to repro the server-side cpu hogging issue locally yet, but the client-side perf degradation when editing status pages is reproducible when a large number of monitors are added to a page (ie. 50+; 72 in my case). Shall I open a separate issue for that while I try against each of the beta versions?
@Eckart0 commented on GitHub (Feb 16, 2026):
I have the same problem with version 2.1.0 – I use Uptime-Kuma as an app/add-on in Home Assistant. Recently, it has been using up a lot of CPU resources - 28-30% just for Uptime-kuma. When I stop the Uptime-Kuma app, overall cpu load returns to 5%
@CommanderStorm commented on GitHub (Feb 16, 2026):
What monitors are you running?
@Eckart0 commented on GitHub (Feb 16, 2026):
Approximately 20 ping monitors
@CommanderStorm commented on GitHub (Feb 16, 2026):
not how many. Which kind and under which options?
@Eckart0 commented on GitHub (Feb 16, 2026):
I have another suspicion: I updated to 2.1.0 with HA, but the monitors are still displayed as version 2.0.1 in the integration. Could there have been a mix-up during the update? This would fit with the fact that HA displayed for some time that an Uptime Koma update was available but could not be installed.