starred/uptime-kuma

Fork 0

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

Webhook notification: Add a checkbox to send alert only when monitored service is down #1899

New issue

Closed

opened 2026-02-28 02:36:27 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-28 02:36:27 -05:00

Owner

Originally created by @amilhub on GitHub (Feb 16, 2023).

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

I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature, Other

🔖 Feature description

In "Notification Type" -> Webhook you should add a checkbox that enable users to send only the webhook alert when monitored service is in status DOWN.

✔️ Solution

¿Why the need of this?
I have configured a simple WebHook URL, with 'shell2http' , so calling the Webhook URL, this trigger a command execution that i previously prefefined, for example a webhook call to http://host.name/restart will do a "simple", 'sytemctl restart httpd'.

How it works now?
I have configured service for monitoring with webhook alert enabled. When service goes down is able to detect and execute de webhook URL, and consecuently the service is restarted.

But, what happens when service comes online again? Obviously the webhook executes again and this cause the service restart (i do not want this, since service is active and currently UP).

This is the reason that a "little" checkbox in the webhook URL alert configuration that can enable us the webhook, only when service alert is DOWN it will be a great and appreciated feature.

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @amilhub on GitHub (Feb 16, 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 UI Feature, Other ### 🔖 Feature description In "Notification Type" -> Webhook you should add a checkbox that enable users to send only the webhook alert when monitored service is in status DOWN. ### ✔️ Solution ¿Why the need of this? I have configured a simple WebHook URL, with 'shell2http' , so calling the Webhook URL, this trigger a command execution that i previously prefefined, for example a webhook call to http://host.name/restart will do a "simple", 'sytemctl restart httpd'. How it works now? I have configured service for monitoring with webhook alert enabled. When service goes down is able to detect and execute de webhook URL, and consecuently the service is restarted. But, what happens when service comes online again? Obviously the webhook executes again and this cause the service restart (i do not want this, since service is active and currently UP). This is the reason that a "little" checkbox in the webhook URL alert configuration that can enable us the webhook, only when service alert is DOWN it will be a great and appreciated feature. ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman

2026-02-28 02:36:27 -05:00

closed this issue
added the
feature-request

A:notifications
labels

deekerman commented

2026-02-28 02:36:32 -05:00

Author

Owner

@kmcbride3 commented on GitHub (Feb 16, 2023):

I did something similar with 'webhookd' and hadn't thought through the loop scenario you're describing. Yes - we need the option to determine whether to fire a notification on UP/DOWN/BOTH for each notification type.

@amilhub - FWIW, after reading your issue, I added a check to see if the service was up/running at the start of my shell script, and only execute the rest if it wasn't. A bit redundant if this change is implemented but at the same time it serves as a safeguard in the event that the webhook is accidentally called (or the script run directly), either by Uptime Kuma or a user when the service is in fact already running.

@kmcbride3 commented on GitHub (Feb 16, 2023): I did something similar with 'webhookd' and hadn't thought through the loop scenario you're describing. Yes - we need the option to determine whether to fire a notification on UP/DOWN/BOTH for each notification type. @amilhub - FWIW, after reading your issue, I added a check to see if the service was up/running at the start of my shell script, and only execute the rest if it wasn't. A bit redundant if this change is implemented but at the same time it serves as a safeguard in the event that the webhook is accidentally called (or the script run directly), either by Uptime Kuma or a user when the service is in fact already running.

deekerman commented

2026-02-28 02:36:32 -05:00

Author

Owner

@amilhub commented on GitHub (Feb 17, 2023):

I did something similar with 'webhookd' and hadn't thought through the loop scenario you're describing. Yes - we need the option to determine whether to fire a notification on UP/DOWN/BOTH for each notification type.

@amilhub - FWIW, after reading your issue, I added a check to see if the service was up/running at the start of my shell script, and only execute the rest if it wasn't. A bit redundant if this change is implemented but at the same time it serves as a safeguard in the event that the webhook is accidentally called (or the script run directly), either by Uptime Kuma or a user when the service is in fact already running.

@kmcbride3 thank you very much for your help and interest.

I never used before 'webhookd' but it seems that is nice, with more options and more flexible than a simple command line execution, i'll give it a try, sure :)

Maybe I could also try in shell2http, before making the 'systemctl restart httpd' make the check if the service is alive as a workaround.

But not always this condition will be valid, i refer for example:

In some cases the service is alive, up and running but the monitored service (ie. web site) is not being served correctly (no receiving the 200 OK, or the text string not matching), so in this case is UP at level service, but is not working as expected and the service reboot is needed in this case.

So, i think for this case a good option could be the following;

Check before the service restart command, if service uptime is more than 2 minutes (for example), so If the Webhook is received, first check if service is alive more than 2 minutes. In this case we can assume that service has no previously rebooted in the previous check and it is "safe" to apply the service restart. On the other hand, if the service has less to 2 min. alive we can asume previous webhook take action and is not needed the service reboot. Maybe it is near a "safe" check that could work as expected, what do you think about it?

I don't know if 'webkookd' it has this kind of service uptime check integrated (not only if a service is up/down) or any workaround is possible.

@amilhub commented on GitHub (Feb 17, 2023): > I did something similar with 'webhookd' and hadn't thought through the loop scenario you're describing. Yes - we need the option to determine whether to fire a notification on UP/DOWN/BOTH for each notification type. > > @amilhub - FWIW, after reading your issue, I added a check to see if the service was up/running at the start of my shell script, and only execute the rest if it wasn't. A bit redundant if this change is implemented but at the same time it serves as a safeguard in the event that the webhook is accidentally called (or the script run directly), either by Uptime Kuma or a user when the service is in fact already running. @kmcbride3 thank you very much for your help and interest. I never used before 'webhookd' but it seems that is nice, with more options and more flexible than a simple command line execution, i'll give it a try, sure :) Maybe I could also try in shell2http, before making the 'systemctl restart httpd' make the check if the service is alive as a workaround. But not always this condition will be valid, i refer for example: In some cases the service is alive, up and running but the monitored service (ie. web site) is not being served correctly (no receiving the 200 OK, or the text string not matching), so in this case is UP at level service, but is not working as expected and the service reboot is needed in this case. So, i think for this case a good option could be the following; Check before the service restart command, if service uptime is more than 2 minutes (for example), so If the Webhook is received, first check if service is alive more than 2 minutes. In this case we can assume that service has no previously rebooted in the previous check and it is "safe" to apply the service restart. On the other hand, if the service has less to 2 min. alive we can asume previous webhook take action and is not needed the service reboot. Maybe it is near a "safe" check that could work as expected, what do you think about it? I don't know if 'webkookd' it has this kind of service uptime check integrated (not only if a service is up/down) or any workaround is possible.

deekerman commented

2026-02-28 02:36:32 -05:00

Author

Owner

@kmcbride3 commented on GitHub (Feb 17, 2023):

@amilhub For what it's worth, I don't think webhookd/http2shell is a factor in this scenario. Both appear to have the same ability to execute a bash script, which is really where all the logic needs to happen once triggered.

For my case, I'm trying to restart a docker container that isn't running (but a specific device must be on/connected in order for it to start), so I do an if statement checking whether the specified container is in 'stopped' status, and only if so, execute the rest of my script (turning on said device, then restarting the container, and turning the device back off).

In your case, you could do a curl command checking for a 200 response (the same as Uptime Kuma is doing), and only attempt to restart the service if it returns anything else.

The intent here is that we are still leaving the regular service uptime checking to Uptime Kuma, and just adding one extra check at the start of the script (that should mirror however the Uptime Kuma monitor is configured).

@kmcbride3 commented on GitHub (Feb 17, 2023): @amilhub For what it's worth, I don't think webhookd/http2shell is a factor in this scenario. Both appear to have the same ability to execute a bash script, which is really where all the logic needs to happen once triggered. For my case, I'm trying to restart a docker container that isn't running (but a specific device must be on/connected in order for it to start), so I do an if statement checking whether the specified container is in 'stopped' status, and only if so, execute the rest of my script (turning on said device, then restarting the container, and turning the device back off). In your case, you could do a curl command checking for a 200 response (the same as Uptime Kuma is doing), and only attempt to restart the service if it returns anything else. The intent here is that we are still leaving the regular service uptime checking to Uptime Kuma, and just adding one extra check at the start of the script (that should mirror however the Uptime Kuma monitor is configured).

deekerman commented

2026-02-28 02:36:32 -05:00

Author

Owner

@Jamie96ITS commented on GitHub (Apr 25, 2023):

I also have a use for this. In addition to the "rebooting services" use case mentioned, I also have an email ticket system that gets notified.

Cold emails sent lack the context needed for the ticket system to associate the up notice with the prior down notice, so each notification starts a new ticket. I'd rather just open the down ticket to investigate the fact that the issue happened at all, and leave the up notice for the other platforms.

So to expand on this, I think this should be an option for all notification types, and not just the Webhooks mentioned.

@Jamie96ITS commented on GitHub (Apr 25, 2023): I also have a use for this. In addition to the "rebooting services" use case mentioned, I also have an email ticket system that gets notified. Cold emails sent lack the context needed for the ticket system to associate the `up` notice with the prior `down` notice, so each notification starts a new ticket. I'd rather just open the `down` ticket to investigate the fact that the issue happened at all, and leave the `up` notice for the other platforms. So to expand on this, I think this should be an option for *all* notification types, and not just the Webhooks mentioned.

deekerman commented

2026-02-28 02:36:32 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 6, 2023):

@amilhub
We are consolidating duplicate issues a bit to make issue management easier.
I think, we should track this issue in #1233 as there is no functional difference (except that this one does only cover webhooks)
⇒ I am going to close this as a duplicate.

@CommanderStorm commented on GitHub (Dec 6, 2023): @amilhub We are consolidating duplicate issues a bit to make issue management easier. I think, we should track this issue in #1233 as there is no functional difference (except that this one does only cover webhooks) ⇒ I am going to close this as a duplicate.