This is a very important feature when this is being used for gateway and ISP monitoring. This should be able to go down to at least 1 second intervals.

This was also requested here: #1015

Seems like key files to resolve this are found here:
https://github.com/louislam/uptime-kuma/search?q=heartbeat+20

I don't see the reason for a minimum when it's self-hosted.

+1. I don't see the reason for a minimum when it's self-hosted.

I don't know, but I think that it was probably added to prevent poor performance with lots of monitors. Having said that, no reason why we couldn't just add a warning saying as much if the user drops it below 20

+1. I don't see the reason for a minimum when it's self-hosted.

I don't know, but I think that it was probably added to prevent poor performance with lots of monitors. Having said that, no reason why we couldn't just add a warning saying as much if the user drops it below 20

Yep. I'd say allow us to shoot ourselves in the foot, but warn that we might do so. 😄

+1. I don't see the reason for a minimum when it's self-hosted.

I don't know, but I think that it was probably added to prevent poor performance with lots of monitors. Having said that, no reason why we couldn't just add a warning saying as much if the user drops it below 20

Yep. I'd say allow us to shoot ourselves in the foot, but warn that we might do so. 😄

How so? Many ping tools has 1sec intervals

any update on this ?

It has been implemented in #1740 and is awaiting merge

we will i be mirg ?

Bumping this... @louislam is there any chance this will be merged soon?

Bumping this... @louislam is there any chance this will be merged soon?

I need to implement some of the changes identified in the PR before it can be merged, most notably requiring the user to confirm that they actually want to go below 20 seconds. More info can be found in the #1740 thread. I will probably get around to implementing this in the next 1 or two weeks

Any movement planned on this? This is definitely a much needed change. 20 seconds is basically an eternity for important/critical/actionable info.

Please refer to what was previously posted

More info can be found in the #1740 thread

TLDR: As long as the performance issues are not resolved, this will not get merged. There are a few performance optimisations implemented in 1.23 and some in 2.0
⇒ let's see if this addresses the issue enough to make this a good change from a support perspective. Adding this without fixing the underlying performance issues is not a thing we can do.

Please refer to what was previously posted

More info can be found in the #1740 thread

TLDR: As long as the performance issues are not resolved, this will not get merged. There are a few performance optimisations implemented in 1.23 and some in 2.0 ⇒ let's see if this addresses the issue enough to make this a good change from a support perspective. Adding this without fixing the underlying performance issues is not a thing we can do.

I haven't looked at the code (and I am, by no means, a professional developer), but, one thing I know is that apps like telegraf, and PRTG, which allow for hundreds of ping sensors with minimal intervals is that they seem to spin a separate thread for every ping. Do you know if this is the same approach Kuma is taking?

I haven't looked at the code (and I am, by no means, a professional developer), but, one thing I know is that apps like telegraf, and PRTG, which allow for hundreds of ping sensors with minimal intervals is that they seem to spin a separate thread for every ping. Do you know if this is the same approach Kuma is taking?

If I remember correctly, the issue is not with the actual running of the tests, but with the backend database, particularly the calculation for the uptime requiring very large queries which end up overloading the database. More info is in #2750.

I too am looking for less than 20 second intervals but I'm guessing this merge is dead now? I mean after 2 years...

In v1 the dangers of such an option are too high (v1 can only cope with a db of 1..10GB depending on storage and retention).
From a support perspective I can't in good faith support merging this.
I am struggling to respond to users/reviewing PRs as is.

See comment from above:

As long as the performance issues are not resolved, this will not get merged. There are a few performance optimisations implemented in 1.23 and some in 2.0
⇒ let's see if this addresses the issue enough to make this a good change from a support perspective. Adding this without fixing the underlying performance issues is not a thing we can do.

=> v2.0 is tracked in #4500 but has some bugs that need adressing before we can release the first beta. If a benchmark gets made we and said benchmark proves that this PR is possible, we can merge it (removing the warning)

I have created a fork of the latest version where the minimum interval is disabled you can find it here:

https://github.com/xvertile/uptime-kuma

Cheers

Can we have any update on this please ?

The situation has not changed from my last post #1645 (comment).
We/someone from the community have not made a benchmark to see if multiplying the load by 20x is acceptable.

Why we are so cautions with this is explained by the fact that 500 monitors @ 20s is equivalent to 25 monitors @ 1s..
v2.0 should better for this usecase, but it might not be enough...

Could you not simply have a warning when setting it lower than 20seconds?

See my last post #1645 (comment)

In v1 the dangers of such an option are too high (v1 can only cope with a db of 1..10GB depending on storage and retention).
From a support perspective I can't in good faith support merging this. I am struggling to respond to users/reviewing PRs as is.

=> without having validated that this is not still a massive footgun/actively dangerous, I won't merge the PR.

I have created a fork of the latest version where the minimum interval is disabled you can find it here:

https://github.com/xvertile/uptime-kuma

Cheers

Great !! Is there a docker image?

Great !! Is there a docker image?

Did you get this tested?