How to change the heartbeat interval to less than 20 seconds? #3416

Closed
opened 2026-02-28 03:28:44 -05:00 by deekerman · 3 comments
Owner

Originally created by @mimishy2000 on GitHub (Jun 18, 2024).

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

  • I checked and didn't find similar issue

🛡️ Security Policy

📝 Describe your problem

I want to ping multiple network devices, but the 20-second interval is too high to accurately monitor network fluctuations, so I want to adjust it to a higher frequency. For example, ping once every second.

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.23.13

💻 Operating System and Arch

centOS 7

🌐 Browser

Google Chrome 124.0.6367.119

🖥️ Deployment Environment

  • Runtime: nodejs 20.14.0
  • Database:
  • Filesystem used to store the database on:
  • number of monitors:
Originally created by @mimishy2000 on GitHub (Jun 18, 2024). ### ⚠️ Please verify that this question 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) ### 📝 Describe your problem I want to ping multiple network devices, but the 20-second interval is too high to accurately monitor network fluctuations, so I want to adjust it to a higher frequency. For example, ping once every second. ### 📝 Error Message(s) or Log _No response_ ### 🐻 Uptime-Kuma Version 1.23.13 ### 💻 Operating System and Arch centOS 7 ### 🌐 Browser Google Chrome 124.0.6367.119 ### 🖥️ Deployment Environment - Runtime: nodejs 20.14.0 - Database: - Filesystem used to store the database on: - number of monitors:
deekerman 2026-02-28 03:28:44 -05:00
  • closed this issue
  • added the
    help
    label
Author
Owner

@CommanderStorm commented on GitHub (Jun 18, 2024):

This is currently not possible due to the performance limits of the current architecture.
See https://github.com/louislam/uptime-kuma/issues/1645 and the associated PR for further details

It might be possible in v2. Nobody has benchmarked if we can reduce this.
Closing as a duplicate

@CommanderStorm commented on GitHub (Jun 18, 2024): This is currently not possible due to the performance limits of the current architecture. See https://github.com/louislam/uptime-kuma/issues/1645 and the associated PR for further details It might be possible in v2. Nobody has benchmarked if we can reduce this. Closing as a duplicate
Author
Owner

@mimishy2000 commented on GitHub (Jun 18, 2024):

This is currently not possible due to the performance limits of the current architecture. See #1645 and the associated PR for further details

It might be possible in v2. Nobody has benchmarked if we can reduce this. Closing as a duplicate

Thank you for your answer. From your reply, is there an option to adjust the heartbeat interval to less than 20 seconds in previous versions? Or which version can I download to achieve this adjustment? We have enough hardware resources to support it, but the current monitoring frequency is too low to accurately monitor network fluctuations. This is the only regret I have. If this option allows users to choose whether to enable it, I think it would be perfect.

@mimishy2000 commented on GitHub (Jun 18, 2024): > This is currently not possible due to the performance limits of the current architecture. See #1645 and the associated PR for further details > > It might be possible in v2. Nobody has benchmarked if we can reduce this. Closing as a duplicate Thank you for your answer. From your reply, is there an option to adjust the heartbeat interval to less than 20 seconds in previous versions? Or which version can I download to achieve this adjustment? We have enough hardware resources to support it, but the current monitoring frequency is too low to accurately monitor network fluctuations. This is the only regret I have. If this option allows users to choose whether to enable it, I think it would be perfect.
Author
Owner

@CommanderStorm commented on GitHub (Jun 19, 2024):

I should have been more precise.
V2 is not yet released. Please see #4500 for further details.

I think that if you want to get around the limits we impose and know that you have a fast, local (no NFS) SSD and have reduced your retention, I think you can get around the limits. As far as I remember we only impose those in the frontend => open the inspector and change the 20 to a 1.

In V1, we don't aggregate results. This means that for every GB of pings that we have to store, the system gets a bit slower. Because our workload is read-write (pings don't stop and nee to be written to disk immediately) and because we are using SQLite which does not like this usage pattern, we time out transactions.

@CommanderStorm commented on GitHub (Jun 19, 2024): I should have been more precise. V2 is not yet released. Please see #4500 for further details. I think that if you want to get around the limits we impose and know that you have a fast, local (no NFS) SSD and have reduced your retention, I think you can get around the limits. As far as I remember we only impose those in the frontend => open the inspector and change the 20 to a 1. In V1, we don't aggregate results. This means that for every GB of pings that we have to store, the system gets a bit slower. Because our workload is read-write (pings don't stop and nee to be written to disk immediately) and because we are using SQLite which does not like this usage pattern, we time out transactions.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uptime-kuma#3416
No description provided.