starred/uptime-kuma

Fork 0

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

Down > Up Retries Option #2080

New issue

Closed

opened 2026-02-28 02:42:20 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-28 02:42:20 -05:00

Owner

Originally created by @1A3Dev on GitHub (Apr 5, 2023).

⚠️ Please verify that this feature request has NOT been suggested before.

I checked and didn't find similar feature request

🏷️ Feature Request Type

Other

🔖 Feature description

If something being monitored is having intermittent issues it causes inaccurate statuses due to the fact it instantly gets marked as Up if it's detected as online so I think it could make sense to have another "Retries" option however instead of checking Up > Down this would check Down > Up.

For example if a website is marked as Down it would then require X amount of heartbeats to return as online before actually marking it as Up.

✔️ Solution

Rename the current "Retries" option to "Down Retries" and add a new option for "Up Retries" which does the same as the existing one however checks Down > Up instead of Up > Down.

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @1A3Dev on GitHub (Apr 5, 2023). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type Other ### 🔖 Feature description If something being monitored is having intermittent issues it causes inaccurate statuses due to the fact it instantly gets marked as Up if it's detected as online so I think it could make sense to have another "Retries" option however instead of checking Up > Down this would check Down > Up. For example if a website is marked as Down it would then require X amount of heartbeats to return as online before actually marking it as Up. ### ✔️ Solution Rename the current "Retries" option to "Down Retries" and add a new option for "Up Retries" which does the same as the existing one however checks Down > Up instead of Up > Down. ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman

2026-02-28 02:42:20 -05:00

closed this issue
added the
feature-request

A:monitor
labels

deekerman commented

2026-02-28 02:42:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 18, 2023):

I would argue that this extra bookkeeping is mostly unnecessary.
In my experience, services mostly don't hover in the up-down state.
=> I would expect, you mostly want to get that notification that things are back okay as soon as possible after addressing the issue.

What is the exact use case you had a problem with Retries?

@CommanderStorm commented on GitHub (May 18, 2023): I would argue that this extra bookkeeping is mostly unnecessary. In my experience, services mostly don't hover in the up-down state. => I would expect, you mostly want to get that notification that things are back okay as soon as possible after addressing the issue. What is the exact use case you had a problem with `Retries`?

deekerman commented

2026-02-28 02:42:25 -05:00

Author

Owner

@1A3Dev commented on GitHub (May 19, 2023):

What is the exact use case you had a problem with Retries?

I had a web server that was intermittently switching between HTTP 200 and 503 which was spamming notifications even with retries set to 2 which would be less spammy if this existed.

@1A3Dev commented on GitHub (May 19, 2023): > What is the exact use case you had a problem with `Retries`? I had a web server that was intermittently switching between HTTP 200 and 503 which was spamming notifications even with retries set to 2 which would be less spammy if this existed.

deekerman commented

2026-02-28 02:42:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 19, 2023):

Okay, but that is something that should not happen => something you WANT to be notified for, right?

@CommanderStorm commented on GitHub (May 19, 2023): Okay, but that is something that should not happen => something you WANT to be notified for, right?

deekerman commented

2026-02-28 02:42:25 -05:00

Author

Owner

@1A3Dev commented on GitHub (May 22, 2023):

Okay, but that is something that should not happen => something you WANT to be notified for, right?

No, the issue was caused by the hosting company where the web server was which I was unable to fix myself. You are correct that I'd want to know it's an intermittent issue but after I discovered that, I wanted a notification when it was fully back up which would be easier with this.

I do agree that it's not a necessary change however it would be a nice quality of life improvement.

I would say that maintenance mode would work to kinda fix the issue of notification spam. However with maintenance mode there's no way to see the current status of the service whilst the maintenance is active which means that isn't a valid option. If the response time graph via the dashboard showed the actual status rather than "maintenance" that would be good alternative solution.

@1A3Dev commented on GitHub (May 22, 2023): > Okay, but that is something that should not happen => something you WANT to be notified for, right? No, the issue was caused by the hosting company where the web server was which I was unable to fix myself. You are correct that I'd want to know it's an intermittent issue but after I discovered that, I wanted a notification when it was fully back up which would be easier with this. I do agree that it's not a necessary change however it would be a nice quality of life improvement. I would say that maintenance mode would work to kinda fix the issue of notification spam. However with maintenance mode there's no way to see the current status of the service whilst the maintenance is active which means that isn't a valid option. If the response time graph via the dashboard showed the actual status rather than "maintenance" that would be good alternative solution.

deekerman commented

2026-02-28 02:42:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 17, 2026):

I think this would be rather hard to explain. Fixing the things you monitor should be the goal and I hope you fixed your issue.

I am going to close this issue, unless there is a more legitemante claim (more than "the thing I am monitoring is broken, I don't care") to why something like this is nessesary or good.
If there is something I missed, we can reopen.

@CommanderStorm commented on GitHub (Jan 17, 2026): I think this would be rather hard to explain. Fixing the things you monitor should be the goal and I hope you fixed your issue. I am going to close this issue, unless there is a more legitemante claim (more than "the thing I am monitoring is broken, I don't care") to why something like this is nessesary or good. If there is something I missed, we can reopen.

deekerman referenced this issue

2026-02-28 02:53:06 -05:00

增加响应时长和异常信息 #2389