How many monitors do you have? What is their type?
10s seems quite long

I am experiencing the same behavior. On initial load it seems very slow, but on subsequent loads it seems much faster. Running 96 monitors (each checking every minute). My database size is 2.3 GB.

Have the same problem with the hanging user interface.
We are using Docker. I am experiencing the issue in the v1.21.3 release as well as the 1.22.0-beta.0 version.

After a container restart, the first time I use UptimeKuma, the monitors are loaded and displayed.
Also the monitoring events work without problems on this first call.

But if I open a second window (No matter which browser or even other devices).
The information is no longer loaded.
The page remains empty.

The first page, however, continues to run without problems. If I refresh the complete page, everything is gone.

Unfortunately there are not really any error messages.

The only thing I see in the Docker log is the message:
[RATE-LIMIT] INFO: remaining requests: 19

Maybe as a side information:

• We have about 700+ monitors running
• The database is about 400 MB in size
• We keep the log data for 7 days.

I'm having the same issue with 216 monitors. Sometimes they randomly display, but then when drilling down they disappear!
I cannot see any errors in the logs.

Running as a container on Docker/Unraid. Version: 1.22.1
DB size: 1.15GB

Has anyone managed to find a solution?

I'm having the same issue. When I log in with a new browser, I only see the WEB UI, no data.
When I check with developer tools, I am only receiving data on the socket.
When i restart via "pm2 restart uptime-kuma" command, i see the data.
However, when I connect with a different browser, I don't see the data again.

monitoring : 716 monitors running
Database size : 1.4gb+
OS : Windows 2012 R2
CPU : Xeon 2.9
Memory : 16GB
Keep Log data : 7 days
uptime kuma version : 1.22.1
node.js version : 18.16.1

Please retest with latest version 1.23

Note that this could be caused by #3515 which is not merged yet.

could be caused

I doubt that it is, given the reported mounitor-count and db-size:

Running 96 monitors [...] My database size is 2.3 GB

@kevin-dunas and @ChrisLStark 's comments are likely not related to this issue and are likely fixed by the PR you linked.
@UllenBullen 's comment might also be.

This might be solved by the call to optimise introduced in #3380 and released in 1.23
=> @Saibamen 's comment if @SlothCroissant can retest if this is a problem in 1.23 is valid
This might also be solved by #3595 or #2750.

I have the same issue.
Running under Proxmox, LXC Debian 12, docker container inside.
Version 1.23.11
DB size: 51.5 MB, keeping only 1 day of history as lowering it seems to improve somehow this issue. At least that was my impression. Might be false.
83 monitors.

Read: with the lowered retention are you still having problems or not?

@CommanderStorm if I understood your question correctly (not sure because of the typos) you are asking if I still have issues with lowered retention. I still do, but seems to happen less often.
Normally this is working OK and after few days the response period is lengthening until becoming really long and I just reboot the machine then. This "few days" is usually about a week.

Why isn't this project utilizing Node worker threads? It's common for the UI to freeze when the thread is blocked by monitor processing, in addition to sqlite3.

Which monitors are you using?
Monitor processing should not be a significant amount of time as all monitors are async and await => allow switching to another part of the codebase.

The usual answer: We just are currently not, no good reason why. Just have not investigated this optimisation.
=> benchmark it to prove that there is a improvement and contribute a fix ^^

Currently, we are monitoring 82 services, including ping, HTTP, DNS, MySQL, MariaDB, MongoDB, PostgreSQL, and others. It is taking more than 60s to load. I recently experimented with adding worker_threads, which significantly enhanced our performance. Could I contribute further to this area?

Yes, sounds obviously interesting. (Duuh..)

Problem is that migrating to the new, way more performant data shema of v2 is not currently done.
=> directly migrating the experiments data (I am assuming you have a high amont of retention configured) won't be possible.

I think if you configure a few hundreds/thousands of monitor @ 20s (see https://pypi.org/project/uptime-kuma-api/) ping and set up a local mock server to ping against you can create a good testcase/"benchmark" for this.
Be aware that some monitors have different scaling requirements.
For example ping is supprisingly CPU intensive => this is an example where I think worker threads might be especially interesting.
Also monitor the impact on RAM (I think that might be the downside of this approach) ^^

Uptime Kuma is designed to be usable in a container with 256MB of memory. Since worker threads is basically a separate node.js instance with its own v8 heap, every thread will take up precious memory and interfere with the memory management of v8 (#3039). Of course there could be a dynamic scaling algorithm based on the available memory, but a lot more engineering effort is needed.

Also, in my limited testing v2 running with an external database has not experienced any performance issues, which suggests to me that the current bottleneck is still on SQlite.

I have been benchmarking why it is taking too many time to load and I found the Monitor.toJSON function. It’s very slow because it fetches lots of data recursively

I met the issue, too.
And my monitoring items are 240.
After trying many ways.

I found a way to resolve that temporarily.

1. Restart the service.
2. Try to open the dashboard. If failed, go to step 1.
3. Select ALL items, and pause them.
4. Try to open the dashboard.
5. Resume ALL the items.
6. The dashboard resumes normal.

Hope this can help you.

@TimK42

You are right, we probably should have added a > [!TIP] to the related issues.
I have updated #4500 with this tip: