Bug: Monitor restarts after deleting heartbeats while paused

[homelab-alpha]

📑 I have found these related issues/pull requests

I have checked, but couldn’t find anything similar.

🛡️ Security Policy

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

📝 Description

When a monitor is paused and the heartbeats are subsequently deleted, the monitor automatically starts again. This behavior is unexpected.

screencast (click to expand)

screencast_uptime_kuma.mp4

👟 Reproduction steps

1. Create a monitor, for example an HTTP(s) monitor for google.com that sends a request every 20 seconds.
2. Wait until several heartbeats have been recorded.
3. Pause the monitor.
   3.1 A toast notification confirms that the monitor is paused.
4. Delete the heartbeats.
   4.1 A toast notification confirms that the monitor status is [Up] 200 - OK.
5. Refresh the page. You will see that the monitor has automatically started again.

Result: The heartbeats are successfully deleted, but the monitor automatically restarts.

👀 Expected behavior

The monitor should remain paused after the heartbeats are deleted.

😓 Actual Behavior

The monitor restarts when the heartbeats are deleted and does not remain paused.

🐻 Uptime-Kuma Version

2.1.0

💻 Operating System and Arch

Ubuntu 24.04.3 LTS (GNU/Linux 6.8.0-94-generic x86_64)

🌐 Browser

Brave 1.86.148 - Chromium: 144.0.7559.133 (Official Build) (64-bit)

🖥️ Deployment Environment

• Runtime Environment:
  • Docker: Version 26.1.0 (Build 9714adc)
  • Docker Compose: Version 2.26.1
  • Portainer (BE): Version 2.33.6 (LTS: Yes)
  • MariaDB: Version 12.1.2 (LTS: Yes)
• Database:
  • MariaDB: External
• Database Storage:
  • Filesystem:
    • Linux: ext4
  • Storage Medium: SSD
• Uptime Kuma Setup:
  • Number of monitors: 99

📝 Relevant log output

No relevant log output for this issue.

[namatery]

I can confirm this behavior on my instance too.

• Uptime Kuma 2.1.0 (Docker)
• Monitor type: PostgreSQL

[ryangurn]

I can confirm that this also happens within 2.1.0-beta.3.

#6398 appears to be what introduced this change.

It appears to be restartMonitor: https://github.com/louislam/uptime-kuma/blob/2d3048937e75c9602688cbeb2466f080f2c724bc/server/server.js#L1654C21-L1654C68

which ends up calling startMonitor:

uptime-kuma/server/server.js

Lines 1866 to 1881 in 2d30489

	async function startMonitor(userID, monitorID) {
	await checkOwner(userID, monitorID);
	log.info("manage", `Resume Monitor: ${monitorID} User ID: ${userID}`);
	await R.exec("UPDATE monitor SET active = 1 WHERE id = ? AND user_id = ? ", [monitorID, userID]);
	let monitor = await R.findOne("monitor", " id = ? ", [monitorID]);
	if (monitor.id in server.monitorList) {
	await server.monitorList[monitor.id].stop();
	}
	server.monitorList[monitor.id] = monitor;
	await monitor.start(io);
	}

Which sets active:

uptime-kuma/server/server.js

Line 1871 in 2d30489

await R.exec("UPDATE monitor SET active = 1 WHERE id = ? AND user_id = ? ", [monitorID, userID]);

[ryangurn]

@namatery & @homelab-alpha does that also occur when you clear statistics too via Settings > Monitor History > Clear all Statistics?

[homelab-alpha]

Hi @ryangurn,

I think so, but I have not tested it.

[ryangurn]

I think just adding a check around the restartMonitor to check if the monitor is active should solve this.

[louislam]

It was affected by #6398

[louislam]

Thanks for the report, it should be fixed.