Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Uptime-Kuma does not respond #4747

Closed
2 tasks done
athamour1 opened this issue May 8, 2024 · 3 comments
Closed
2 tasks done

Uptime-Kuma does not respond #4747

athamour1 opened this issue May 8, 2024 · 3 comments
Labels
help

Comments

@athamour1
Copy link

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

  • I checked and didn't find similar issue

🛡️ Security Policy

📝 Describe your problem

I have an instance of uptime-kuma added something like 100 monitors, the UI doesn't respond anymore, this is due to the volume of the monitors ?
Or this is normal ?
Also, another one is that the application is running and can send notifications when a monitor is down, the UI doesn't respond only.
image

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.23.13

💻 Operating System and Arch

Helm Chart from Docker compose

🌐 Browser

I tried it from the latest firefox and from the latest chrome

🖥️ Deployment Environment

  • Runtime: ContainerD (K3S)
  • Database: SQLite
  • Filesystem used to store the database on: Kubernetes localfs (BTRFS)
  • number of monitors: 105
@athamour1 athamour1 added the help label May 8, 2024
@athamour1
Copy link
Author

After a quick restart of the service, the monitors are back, but this is not very stable, is there any way to improve the stability of the Frontend ?

@CommanderStorm
Copy link
Collaborator

Please see #3276 which this is a duplicate of or #4500 which tracks the resolution with this tip:

Tip

If you are affected by the performance limits mentoned in the v2-tracking issue in v1, you need to reduce the amount of data you store.
The core problem is that Uptime Kuma in v1 has to do a table scan of the entire heartbeat table for some operations.

The solution boils down to having a lower amount of data => making Uptime Kuma less worried about reading those gigabytes of data.:

  • reduce the retention and execute a manual cleanup under /settings/monitor-history
  • Increase the time between checks
  • pause or reduce the amount of monitors
  • delete the specific history of less essential monitors (to "lower" their retention below the configured maximum)

@CommanderStorm
Copy link
Collaborator

(closing as a duplicate)

@CommanderStorm CommanderStorm closed this as not planned Won't fix, can't repro, duplicate, stale May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@CommanderStorm @athamour1