[1.23.X] Long timeouts causes monitor to restart #2810

New issue

Open

opened 2026-02-28 03:08:04 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-28 03:08:04 -05:00

Owner

Originally created by @chakflying on GitHub (Nov 19, 2023).

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

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

Description

From #4039:

1.23.X does not have the accurate interval fix (https://github.com/louislam/uptime-kuma/pull/3072). This means that any blocking timeout would count towards the beat interval.
When the beat interval is set to 60, and timeout is set to 48, part of that 48 seconds gets counted towards the beat interval.
In practice, this means that continuously timing-out would pass the threshold where checkMonitors would consider it as stuck.
```
[MONITOR_CHECKER] ERROR: Monitor Interval: 60 Monitor 1 lastStartBeatTime diff: 95
[MONITOR_CHECKER] ERROR: Unexpected error: Monitor 1 is struck for unknown reason
```
Hence the monitor is restarted, retries gets reset, and notifications get sent again.

I think we should either backport https://github.com/louislam/uptime-kuma/pull/3072, or increase the checkMonitors tolerance to prevent this.

👟 Reproduction steps

Create HTTP monitor with target https://199.199.199.199, retries 1, interval 60 and timeout 48.
Observe that retries gets reset periodically, depending on the alignment of the checkMonitors interval and the monitor's interval.

👀 Expected behavior

Timeouts should not cause monitor to restart

😓 Actual Behavior

Timeouts causes monitor to restart

🐻 Uptime-Kuma Version

1.23.6

💻 Operating System and Arch

Debian 12

🌐 Browser

Mozilla Firefox

🐋 Docker Version

Docker 24.0.7

🟩 NodeJS Version

No response

📝 Relevant log output

No response

Originally created by @chakflying on GitHub (Nov 19, 2023). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description From #4039: - 1.23.X does not have the accurate interval fix (https://github.com/louislam/uptime-kuma/pull/3072). This means that any blocking timeout would count towards the beat interval. - When the beat interval is set to 60, and timeout is set to 48, part of that 48 seconds gets counted towards the beat interval. - In practice, this means that continuously timing-out would pass the threshold where `checkMonitors` would consider it as stuck. ``` [MONITOR_CHECKER] ERROR: Monitor Interval: 60 Monitor 1 lastStartBeatTime diff: 95 [MONITOR_CHECKER] ERROR: Unexpected error: Monitor 1 is struck for unknown reason ``` Hence the monitor is restarted, retries gets reset, and notifications get sent again. I think we should either backport https://github.com/louislam/uptime-kuma/pull/3072, or increase the checkMonitors tolerance to prevent this. ### 👟 Reproduction steps 1. Create HTTP monitor with target `https://199.199.199.199`, retries `1`, interval `60` and timeout `48`. 2. Observe that retries gets reset periodically, depending on the alignment of the `checkMonitors` interval and the monitor's interval. ### 👀 Expected behavior Timeouts should not cause monitor to restart ### 😓 Actual Behavior Timeouts causes monitor to restart ### 🐻 Uptime-Kuma Version 1.23.6 ### 💻 Operating System and Arch Debian 12 ### 🌐 Browser Mozilla Firefox ### 🐋 Docker Version Docker 24.0.7 ### 🟩 NodeJS Version _No response_ ### 📝 Relevant log output _No response_