UI actions take 45s with 700 monitors (edit/delete/load) - v2.1.3 performance bug

[paugarciauve]

📑 I have found these related issues/pull requests

Matches Reddit: https://www.reddit.com/r/UptimeKuma/comments/1qqdydb/is_uptime_kuma_scalable_enough_to_monitor_12k/

• Very slow with 1000+ monitors #5641: "Very slow with 1000+ monitors" (1400 monitors, 10-15s load) Very slow with 1000+ monitors #5641
• Main dashboard slow when adding too many monitors #6181: "Main dashboard slow when adding too many monitors" (900 monitors) Main dashboard slow when adding too many monitors #6181
• Slowness with 100% CPU utilization #2889: "Slowness with 100% CPU utilization" (350+ monitors) Slowness with 100% CPU utilization #2889
• Dashboard takes forever to load  #1397: "Dashboard takes forever to load" Dashboard takes forever to load  #1397
• Web UI Hanging #3276: "Web UI Hanging" (slow initial load) Web UI Hanging #3276

🛡️ Security Policy

• I have read and agree to Uptime Kuma's Security Policy.

📝 Description

With 700 monitors, EVERY SINGLE UI ACTION takes ~45 seconds:

• Load dashboard → 45s
• Edit monitor → 45s
• Delete monitor → 45s
  No errors. No CPU spikes. Pure slowness scales with monitor count.

Every UI interaction triggers massive SELECT queries loading ALL 700 monitors (no pagination/caching). Frontend waits for complete dataset before any action completes.

👟 Reproduction steps

1. Uptime Kuma v2.1.3 + MariaDB on Kubernetes
2. Create 700 active monitors
3. Open dashboard → 45s load
4. Click ANY monitor → Edit → Save → 45s delay
5. Repeat for any UI navigation → consistent 45s delays

👀 Expected behavior

• Dashboard loads in <2 seconds
• Monitor edits/deletes complete in <2 seconds
• ANY UI action instant regardless of monitor count

😓 Actual Behavior

• Initial dashboard load: ~45s spinner
• Edit ANY monitor → Save: ~45s delay
• Delete ANY monitor: ~45s delay
• Switch pages/dropdowns: ~45s delays
• 700 monitors = EVERY action takes 45s

🐻 Uptime-Kuma Version

2.1.3

💻 Operating System and Arch

macOS (latest MacBook Pro)

🌐 Browser

Microsoft Edge (latest version)

🖥️ Deployment Environment

Runtime Environment:

• Docker: 26.1.4 (Build 27.2.0)
• Kubernetes (K8S): 1.33.2 (via kubectl/helm)
• MariaDB: 11.4.2 (External, separate StatefulSet)
• Node.js: 20.18.0 (LTS: Yes)

Database:

• MariaDB: External

Database Storage:

• Filesystem: ext4 (Linux nodes)
• Storage Medium: NVMe SSD

Uptime Kuma Setup:

• Number of monitors: 700 (HTTP/TCP/Ping/Heartbeat)

[romainl63]

Hi,

The same thing happens to me, but with far fewer monitors and concerning the status pages.
A status page with 85 monitors is impossible to manage because the interface is so slow that it causes the page to crash completely, regardless of the web browser.
In previous versions, I didn't have this problem, even though the more monitors there are on a status page, the less fluid the interface is.
To overcome this problem, I completely redesigned my status pages because I could no longer add any monitors to them.

Translated with DeepL.com (free version)

[louislam]

85 monitors is impossible to manage

85 should be ok.

Unfortunately, there should be some bad changes added in 2.1.0, which I am not to identify, since there were too many contributions in 2.1.0.

Related issues:
#6935
#6888

Also it is also hard for me to reproduce. If I cannot reproduce, I will not be able to fix the root cause.

So it pretty much needs you guys' help to find the root cause.

[louislam]

For MariaDB, you can use this to check which query is slow.
SHOW PROCESSLIST

[paugarciauve]

For MariaDB, you can use this to check which query is slow. SHOW PROCESSLIST

Hi @louislam, thanks for your quick reply. The issue doesn’t come from the database — it’s the Uptime Kuma front end that doesn’t perform well when there are around 600 monitors or more. If you’d like, I can send you a script to quickly recreate my case and generate that number of monitors.

[CommanderStorm]

Sure, I would love a performance benchmark. Currently, we don't have those.

If they are simple to run, that would be a lovely contribution.

[paugarciauve]

Hi,
I’ve created a brand new and clean Kuma instance and loaded 600 monitors using the following script xxx. I noticed that when creating 600 “Ping” type monitors in a loop, the platform takes between 0 and 8 seconds to load. That’s a bit of load, but 8 seconds seems reasonable.

from uptime_kuma_api import UptimeKumaApi, MonitorType
KUMA_URL = "http://localhost:3001"
KUMA_USER = "xxx"
KUMA_PASS = "xxx"

with UptimeKumaApi(KUMA_URL) as api:
    api.login(KUMA_USER, KUMA_PASS)

    for i in range(1, 601):
        api.add_monitor(
            type=MonitorType.HTTP,
            name=f"ping {i}",
            hostname="https://google.com",
            interval=60,
            retryInterval=60,
            maxretries=3,
        )
        print(f"[{i}/600] ping {i} created")

Another test I did—since I use it quite often—is with the “Microsoft SQL Server” monitor type. In this case, I loaded around 300 monitors through a script that runs a relatively simple query against my production machines. Unfortunately, I can’t share this script because it contains sensitive information.
In this test, when loading 100 monitors, the frontend takes approximately 20 seconds to load.

Summary:

0 monitors → 0 seconds
600 Ping monitors → 8 seconds
600 ping monitors + 150 Microsoft SQL monitors --> 18 seconds

[CommanderStorm]

Thanks for putting the effort into benchmarking this and sharing the results.

Since the script uses external tooling (uptime_kuma_api), it would be a bit harder to integrate directly into the repository as a benchmark. For something that lives in the codebase, it would ideally:

• Be written in JavaScript/Node.js (to match the project stack)
• Use the same Socket.IO communication the frontend uses to create monitors
• Provide a measurable benchmark (e.g., "internal API route X takes Y ms with N monitors")

That way it could run as a reproducible benchmark within the repo itself.

That said, the numbers you shared are still useful and give a good starting point if someone wants to investigate the performance characteristics further.
If someone is interested in contributing a benchmark setup (or improving performance for larger numbers of monitors), this should be a fairly simple thing to add.

[paugarciauve]

Here we have a script that creates 600 monitors HTTPS in a new kuma just need, in .mjs, to set the variables UPTIME_KUMA_PASSWORD, UPTIME_KUMA_USERNAME, UPTIME_KUMA_URL, i tested and it works fine

/**
 * Script to bulk-create 600 HTTPS monitors pointing to google.com
 *
 * Usage:
 *   node extra/create-bulk-monitors.mjs [options]
 *
 * Options (env vars or edit the CONFIG block below):
 *   UPTIME_KUMA_URL      Base URL of your Uptime Kuma instance  (default: http://localhost:3001)
 *   UPTIME_KUMA_USERNAME Login username                          (default: admin)
 *   UPTIME_KUMA_PASSWORD Login password                          (default: admin)
 *   MONITOR_COUNT        How many monitors to create             (default: 600)
 *   CONCURRENCY          Parallel monitors created at once       (default: 5)
 */

import { io } from "socket.io-client";

// ─── CONFIG ──────────────────────────────────────────────────────────────────
const BASE_URL      = process.env.UPTIME_KUMA_URL      ?? "http://localhost:3001";
const USERNAME      = process.env.UPTIME_KUMA_USERNAME ?? "xxx";
const PASSWORD      = process.env.UPTIME_KUMA_PASSWORD ?? "xxx";
const MONITOR_COUNT = Number(process.env.MONITOR_COUNT  ?? 600);
const CONCURRENCY   = Number(process.env.CONCURRENCY    ?? 5);
// ─────────────────────────────────────────────────────────────────────────────

/** Wraps socket.emit in a Promise */
function emit(socket, event, ...args) {
    return new Promise((resolve, reject) => {
        socket.emit(event, ...args, (res) => {
            if (res?.ok) {
                resolve(res);
            } else {
                reject(new Error(res?.msg ?? "Unknown error"));
            }
        });
    });
}

/** Connects to the Uptime Kuma Socket.IO server */
function connect() {
    return new Promise((resolve, reject) => {
        const socket = io(BASE_URL, {
            reconnection: false,
            transports: ["websocket"],
        });

        socket.once("connect", () => resolve(socket));
        socket.once("connect_error", (err) => reject(err));
    });
}

/** Login and return the socket ready to use */
async function login(socket) {
    const res = await emit(socket, "login", {
        username: USERNAME,
        password: PASSWORD,
        token: "",
    });
    console.log(`✓ Logged in as "${USERNAME}"`);
    return res;
}

/** Build the monitor payload for a single HTTPS monitor */
function buildMonitor(index) {
    return {
        type: "http",
        name: `Google HTTPS #${String(index).padStart(4, "0")}`,
        url: "https://www.google.com",
        method: "GET",
        interval: 60,
        retryInterval: 60,
        resendInterval: 0,
        maxretries: 1,
        timeout: 48,
        ignoreTls: false,
        upside_down: false,
        maxredirects: 10,
        accepted_statuscodes: ["200-299"],
        notificationIDList: {},
        active: true,
    };
}

/** Run tasks with limited concurrency */
async function pLimit(tasks, concurrency) {
    const results = [];
    let index = 0;

    async function runNext() {
        while (index < tasks.length) {
            const current = index++;
            results[current] = await tasks[current]();
        }
    }

    const workers = Array.from({ length: Math.min(concurrency, tasks.length) }, runNext);
    await Promise.all(workers);
    return results;
}

async function main() {
    console.log(`Connecting to ${BASE_URL} …`);
    const socket = await connect();
    console.log("✓ Connected");

    await login(socket);

    let created = 0;
    let failed  = 0;

    const tasks = Array.from({ length: MONITOR_COUNT }, (_, i) => async () => {
        const monitor = buildMonitor(i + 1);
        try {
            const res = await emit(socket, "add", monitor);
            created++;
            process.stdout.write(`\r  Progress: ${created + failed}/${MONITOR_COUNT}  (✓ ${created}  ✗ ${failed})`);
            return res.monitorID;
        } catch (err) {
            failed++;
            process.stdout.write(`\r  Progress: ${created + failed}/${MONITOR_COUNT}  (✓ ${created}  ✗ ${failed})`);
            console.error(`\n  ✗ Monitor #${i + 1} failed: ${err.message}`);
            return null;
        }
    });

    console.log(`\nCreating ${MONITOR_COUNT} HTTPS monitors (concurrency=${CONCURRENCY}) …`);
    await pLimit(tasks, CONCURRENCY);

    console.log(`\n\nDone! Created: ${created}  Failed: ${failed}`);
    socket.disconnect();
    process.exit(failed > 0 ? 1 : 0);
}

main().catch((err) => {
    console.error("Fatal error:", err.message);
    process.exit(1);
});