starred/uptime-kuma

Fork 0

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

Constant CPU usage #862

New issue

Closed

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

deekerman commented

2026-02-28 02:01:37 -05:00

Owner

Originally created by @iamnague on GitHub (Feb 22, 2022).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

Description

I'm running Uptime-Kuma in docker.
Even with 0 monitoring probe, cpu usage for this docker is constant 0,25%.

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
9483fa2235c0        uptime-kuma         0.25%               47.75MiB / 11.71GiB   0.40%               49.4MB / 49.1MB     193kB / 154MB       12

The VM has 2 vCPU. Is this a normal behavior ?
I tested other dockers based on node.js, cpu usage is nearly 0%, or 0,01% when idle.

👟 Reproduction steps

Run uptime-kuma in docker then docker stats

👀 Expected behavior

cpu usage arround 0% when idle

😓 Actual Behavior

0,25%

🐻 Uptime-Kuma Version

1.11.4

💻 Operating System and Arch

linux/amd64

🌐 Browser

firefox

🐋 Docker Version

Docker 18.06.2

🟩 NodeJS Version

No response

📝 Relevant log output

No response

Originally created by @iamnague on GitHub (Feb 22, 2022). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description I'm running Uptime-Kuma in docker. Even with 0 monitoring probe, cpu usage for this docker is constant 0,25%. ``` CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS 9483fa2235c0 uptime-kuma 0.25% 47.75MiB / 11.71GiB 0.40% 49.4MB / 49.1MB 193kB / 154MB 12 ``` The VM has 2 vCPU. Is this a normal behavior ? I tested other dockers based on node.js, cpu usage is nearly 0%, or 0,01% when idle. ### 👟 Reproduction steps Run uptime-kuma in docker then docker stats ### 👀 Expected behavior cpu usage arround 0% when idle ### 😓 Actual Behavior 0,25% ### 🐻 Uptime-Kuma Version 1.11.4 ### 💻 Operating System and Arch linux/amd64 ### 🌐 Browser firefox ### 🐋 Docker Version Docker 18.06.2 ### 🟩 NodeJS Version _No response_ ### 📝 Relevant log output _No response_

deekerman

2026-02-28 02:01:37 -05:00

closed this issue
added the
invalid
label

deekerman commented

2026-02-28 02:01:42 -05:00

Author

Owner

@louislam commented on GitHub (Feb 23, 2022):

It is normal, because it is not completely idle actually.

@louislam commented on GitHub (Feb 23, 2022): It is normal, because it is not completely idle actually.

deekerman commented

2026-02-28 02:01:42 -05:00

Author

Owner

@kroese commented on GitHub (May 17, 2022):

@louislam I have the same issue as described here. Kuma is constantly using 1 to 2 procent of my CPU.

Ofcourse it can never be completely idle, but compared to my other containers it uses a lot of CPU time, especially for such a small task.

Is there any reason why? Ideally it should be able to sleep 99 procent of the time, wakeup for a monitor, and go back to sleep. Why is it constantly hammering the CPU?

@kroese commented on GitHub (May 17, 2022): @louislam I have the same issue as described here. Kuma is constantly using 1 to 2 procent of my CPU. Ofcourse it can never be completely idle, but compared to my other containers it uses a lot of CPU time, especially for such a small task. Is there any reason why? Ideally it should be able to sleep 99 procent of the time, wakeup for a monitor, and go back to sleep. Why is it constantly hammering the CPU?

deekerman referenced this issue

2026-02-28 02:02:35 -05:00

Static/ manual Uptime Monitor with no Uptime Check #885

deekerman referenced this issue

2026-02-28 02:35:10 -05:00

Multiple Incidents #1857

deekerman referenced this issue

2026-02-28 02:39:51 -05:00

Add More Details in status page #2000