Configurable Buffer for Notifications #819

New issue

Closed

opened 2026-02-28 02:00:13 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-28 02:00:13 -05:00

Owner

Originally created by @WS-JamesPlant on GitHub (Feb 8, 2022).

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

I checked and didn't find similar feature request

🏷️ Feature Request Type

New Notification, Other

🔖 Feature description

I use uptime kuma for monitoring lots of different things and it is excellent, thank you.

I have also configured the notifications, however, there will be instances where we get a single timeout. This isn't always a true down time event, it may just be network conditions etc. If we are monitoring a third party API that we are relying on and there is a single time out. I don't necessarily want to get notified immediately. I'd rather wait until we have checked a couple of times, if it is down for multiple checks, then I want to get the notification so I know there is a true problem.

Basically I'd like to configure a buffer, where notifications do not get sent until the number of sequential failed checks is greater than the buffer value.

✔️ Solution

I would like an option on a monitor, where we can configure a buffer value. The service as down and does not trigger notifications until this number of checks have failed in a row greater or equal to the value configured as the buffer.

❓ Alternatives

We could have this as a global configuration option, or as an option on the notification setup

📝 Additional Context

No response

Originally created by @WS-JamesPlant on GitHub (Feb 8, 2022). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type New Notification, Other ### 🔖 Feature description I use uptime kuma for monitoring lots of different things and it is excellent, thank you. I have also configured the notifications, however, there will be instances where we get a single timeout. This isn't always a true down time event, it may just be network conditions etc. If we are monitoring a third party API that we are relying on and there is a single time out. I don't necessarily want to get notified immediately. I'd rather wait until we have checked a couple of times, if it is down for multiple checks, then I want to get the notification so I know there is a true problem. Basically I'd like to configure a buffer, where notifications do not get sent until the number of sequential failed checks is greater than the buffer value. ### ✔️ Solution I would like an option on a monitor, where we can configure a buffer value. The service as down and does not trigger notifications until this number of checks have failed in a row greater or equal to the value configured as the buffer. ### ❓ Alternatives We could have this as a global configuration option, or as an option on the notification setup ### 📝 Additional Context _No response_

deekerman

2026-02-28 02:00:13 -05:00

closed this issue
added the
feature-request
label

deekerman commented

2026-02-28 02:00:18 -05:00

Author

Owner

@rezzorix commented on GitHub (Feb 8, 2022):

If I understood your request right, then this is already available:

See in each monitor the option under the heartbeat interval:

Retries
Maximum retries before the service is marked as down and a notification is sent

@rezzorix commented on GitHub (Feb 8, 2022): If I understood your request right, then this is already available: See in each monitor the option under the heartbeat interval: **Retries** _Maximum retries before the service is marked as down and a notification is sent_

deekerman commented

2026-02-28 02:00:18 -05:00

Author

Owner

@WS-JamesPlant commented on GitHub (Feb 8, 2022):

Yes, you are correct! I apologise I completely missed this. Thank you!

@WS-JamesPlant commented on GitHub (Feb 8, 2022): Yes, you are correct! I apologise I completely missed this. Thank you!

deekerman referenced this issue

2026-02-28 02:39:37 -05:00

monitor server load and cpu/ram/disk usage #1994

deekerman referenced this issue

2026-02-28 02:39:37 -05:00