starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Enhancement: Thresholds #41

New issue

Closed

opened 2026-02-28 01:32:47 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-28 01:32:47 -05:00

Owner

Originally created by @aslmx on GitHub (Jul 14, 2021).

Thanks for this project!
Its lean and seems to work so far!

What I'd really love to see extended is the notification functionality.

Wouldn't it be nice to have a threshold, for example for Pings, before an Alarm triggers?

my Internet pretty much disconnects every 8-48 hours once for 1-2 minutes.

Would be cool to tell Uptime Kuma to only send a notification if minimum X failed attempts happened.

Thanks for considering!

Originally created by @aslmx on GitHub (Jul 14, 2021). Thanks for this project! Its lean and seems to work so far! What I'd really love to see extended is the notification functionality. Wouldn't it be nice to have a threshold, for example for Pings, before an Alarm triggers? my Internet pretty much disconnects every 8-48 hours once for 1-2 minutes. Would be cool to tell Uptime Kuma to only send a notification if minimum X failed attempts happened. Thanks for considering!

deekerman

2026-02-28 01:32:47 -05:00

closed this issue
added the
feature-request
label

deekerman commented

2026-02-28 01:32:53 -05:00

Author

Owner

@Panja0 commented on GitHub (Jul 14, 2021):

We’ve got this covered already in #21

Retries: for instance 3 retries in xx seconds before a service is being marked as down

@Panja0 commented on GitHub (Jul 14, 2021): We’ve got this covered already in #21 Retries: for instance 3 retries in xx seconds before a service is being marked as down

deekerman commented

2026-02-28 01:32:54 -05:00

Author

Owner

@aslmx commented on GitHub (Jul 14, 2021):

Thanks for pointing out. Hadn't seen that when looking if it was already mentioned.
(working in QA, my experience is to address each thing in a single ticket/defect/issue, so it is easier to later resolve them one by one, instead of having one mutating issue which never gets closed ;-) - just a suggestion though).

@aslmx commented on GitHub (Jul 14, 2021): Thanks for pointing out. Hadn't seen that when looking if it was already mentioned. (working in QA, my experience is to address each thing in a single ticket/defect/issue, so it is easier to later resolve them one by one, instead of having one mutating issue which never gets closed ;-) - just a suggestion though).

deekerman commented

2026-02-28 01:32:54 -05:00

Author

Owner

@Panja0 commented on GitHub (Jul 14, 2021):

I get what you mean! Makes sense.
I’ll leave it up to the dev which way he prefers.

Cheers!

@Panja0 commented on GitHub (Jul 14, 2021): I get what you mean! Makes sense. I’ll leave it up to the dev which way he prefers. Cheers!

deekerman commented

2026-02-28 01:32:54 -05:00

Author

Owner

@louislam commented on GitHub (Jul 15, 2021):

Thanks for pointing out. Hadn't seen that when looking if it was already mentioned.
(working in QA, my experience is to address each thing in a single ticket/defect/issue, so it is easier to later resolve them one by one, instead of having one mutating issue which never gets closed ;-) - just a suggestion though).

Agree with this, I actually added version number in the frontend which mentioned in #21, but it is hard to mark as resolved.

@louislam commented on GitHub (Jul 15, 2021): > Thanks for pointing out. Hadn't seen that when looking if it was already mentioned. > (working in QA, my experience is to address each thing in a single ticket/defect/issue, so it is easier to later resolve them one by one, instead of having one mutating issue which never gets closed ;-) - just a suggestion though). Agree with this, I actually added version number in the frontend which mentioned in #21, but it is hard to mark as resolved.

deekerman commented

2026-02-28 01:32:54 -05:00

Author

Owner

@Panja0 commented on GitHub (Jul 15, 2021):

@louislam
Ok I understand. What do you suggest?
I can create tickets for all individual request or I can edit my post when something has been resolved. What works best for you?!

@Panja0 commented on GitHub (Jul 15, 2021): @louislam Ok I understand. What do you suggest? I can create tickets for all individual request or I can edit my post when something has been resolved. What works best for you?!

deekerman commented

2026-02-28 01:32:54 -05:00

Author

Owner

@louislam commented on GitHub (Jul 15, 2021):

@louislam
Ok I understand. What do you suggest?
I can create tickets for all individual request or I can edit my post when something has been resolved. What works best for you?!

I just discovered that github provides checkbox syntax. Maybe you can prepend a checkbox for each request, so that I can mark as resolved.

@louislam commented on GitHub (Jul 15, 2021): > @louislam > Ok I understand. What do you suggest? > I can create tickets for all individual request or I can edit my post when something has been resolved. What works best for you?! ![image](https://user-images.githubusercontent.com/1336778/125811679-3977f994-08d2-4b6b-b8b3-2b8fd83838cc.png) I just discovered that github provides checkbox syntax. Maybe you can prepend a checkbox for each request, so that I can mark as resolved.

deekerman commented

2026-02-28 01:32:54 -05:00

Author

Owner

@Panja0 commented on GitHub (Jul 15, 2021):

@louislam done!

@Panja0 commented on GitHub (Jul 15, 2021): @louislam done!

deekerman commented

2026-02-28 01:32:54 -05:00

Author

Owner

@louislam commented on GitHub (Jul 30, 2021):