⚠️ Please verify that this questio

Please see <a class="issue-link js-issue-link" data-error-text="Failed to load title"

Uptime-Kuma does not respond about uptime-kuma HOT 3 CLOSED

athamour1 commented on July 17, 2024 1

Uptime-Kuma does not respond

from uptime-kuma.

Comments (3)

CommanderStorm commented on July 17, 2024 1

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

better performance through external MariaDB, storing heartbeats in an aggregated form, full server-side pagination for important events
=> even though benchmarking is still out, we are confident that this pushes the prominent "limits" (highly hardware-dependent, not a limit imposed by us) ~500 Monitor or ~1.5GB DB-size
A large part of the focus in this release is on performance. We don't know if we are optimising for the right thing, see #4456 for a discussion on this topic.

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)

from uptime-kuma.

athamour1 commented on July 17, 2024

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 ?

from uptime-kuma.

CommanderStorm commented on July 17, 2024

(closing as a duplicate)

from uptime-kuma.

Recommend Projects