starred/uptime-kuma

Fork 0

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

Being able to edit the notification that is being sent out #2090

New issue

Closed

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

deekerman commented

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

Owner

Originally created by @4n0nh4x0r on GitHub (Apr 8, 2023).

⚠️ 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, UI Feature

🔖 Feature description

As the title already says.
It would be nice to be able to specify what a notification sends.
Like for example, if i dont want to expose the ip address of the server where my backend service runs on, it would be nice to be able to at least disabled that the notification sends out the service url.
Even better would be being able to fully customize the notification but well, i can assume how much work that would be, so it would already be nice to just be able to toggle the visibility of certain parts of the message.

✔️ Solution

Having options in the notification setup that you can toggle to enable/disable this specific notification from showing a certain part of the information like for example the service url or the ping.
At least a toggle to disable the service url from being shown on the notification you are editing.

❓ Alternatives

Alternatively one could allow the user to create their own notification with maybe a specific json object template they have to edit themselves, or just some text boxes that fill the json object behind the scenes

📝 Additional Context

No response

Originally created by @4n0nh4x0r on GitHub (Apr 8, 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 New Notification, UI Feature ### 🔖 Feature description As the title already says. It would be nice to be able to specify what a notification sends. Like for example, if i dont want to expose the ip address of the server where my backend service runs on, it would be nice to be able to at least disabled that the notification sends out the service url. Even better would be being able to fully customize the notification but well, i can assume how much work that would be, so it would already be nice to just be able to toggle the visibility of certain parts of the message. ### ✔️ Solution Having options in the notification setup that you can toggle to enable/disable this specific notification from showing a certain part of the information like for example the service url or the ping. At least a toggle to disable the service url from being shown on the notification you are editing. ### ❓ Alternatives Alternatively one could allow the user to create their own notification with maybe a specific json object template they have to edit themselves, or just some text boxes that fill the json object behind the scenes ### 📝 Additional Context _No response_

deekerman

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

closed this issue
added the
feature-request

A:notifications
labels

deekerman commented

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

Author

Owner

@jonnymccullagh commented on GitHub (Apr 14, 2023):

I would like this too, with another (optional) textbox under 'Description' for 'Notification Message' that could include info on how to deal with the problem or a link to a Playbook.

@jonnymccullagh commented on GitHub (Apr 14, 2023): I would like this too, with another (optional) textbox under 'Description' for 'Notification Message' that could include info on how to deal with the problem or a link to a Playbook.

deekerman commented

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

Author

Owner

@4n0nh4x0r commented on GitHub (Apr 14, 2023):

I would like this too, with another (optional) textbox under 'Description' for 'Notification Message' that could include info on how to deal with the problem or a link to a Playbook.

ooooo, it would be nice to be able to automate actions if something goes south
like for example making it so if a service goes down lets say in the middle of the night and you dont notice it being down for lets say 5 minutes, that the system automatically tries to restart the service or even the whole server
but it would also be nice to be able to set custom responses for certain error codes, for example if a nextcloud server gives out a 500 error, yknow that something is really going wrong, possibly a redis server or the db server down or something like that, and then the notification could tell you the error code and what problems could be causing this (tho this would be more of a manual thing to add as a custom message)

@4n0nh4x0r commented on GitHub (Apr 14, 2023): > I would like this too, with another (optional) textbox under 'Description' for 'Notification Message' that could include info on how to deal with the problem or a link to a Playbook. ooooo, it would be nice to be able to automate actions if something goes south like for example making it so if a service goes down lets say in the middle of the night and you dont notice it being down for lets say 5 minutes, that the system automatically tries to restart the service or even the whole server but it would also be nice to be able to set custom responses for certain error codes, for example if a nextcloud server gives out a 500 error, yknow that something is really going wrong, possibly a redis server or the db server down or something like that, and then the notification could tell you the error code and what problems could be causing this (tho this would be more of a manual thing to add as a custom message)

deekerman commented

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

Author

Owner

@CommanderStorm commented on GitHub (Jun 4, 2023):

@4n0nh4x0r is this a duplicate of #1529 #2661 https://github.com/louislam/uptime-kuma/issues/2617 https://github.com/louislam/uptime-kuma/issues/2387 and more (see #646 for a deeper discussion)

If yes, please close this issue. Duplicates just make issue management harder.
If no, please edit the title+description to make this more distinct (and comment to notify the other participants)

@CommanderStorm commented on GitHub (Jun 4, 2023): @4n0nh4x0r is this a duplicate of #1529 #2661 https://github.com/louislam/uptime-kuma/issues/2617 https://github.com/louislam/uptime-kuma/issues/2387 and more (see #646 for a deeper discussion) If yes, please close this issue. Duplicates just make issue management harder. If no, please edit the title+description to make this more distinct (and comment to notify the other participants)

deekerman commented

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

Author

Owner

@jonnymccullagh commented on GitHub (Jun 5, 2023):

Yes duplicate of https://github.com/louislam/uptime-kuma/issues/646 - I would say close this issue

@jonnymccullagh commented on GitHub (Jun 5, 2023): Yes duplicate of https://github.com/louislam/uptime-kuma/issues/646 - I would say close this issue

deekerman commented

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

Author

Owner

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

@4n0nh4x0r could you close this issue?
(only you or Louis can close issues for permission reasons)

@CommanderStorm commented on GitHub (Jun 6, 2023): @4n0nh4x0r could you close this issue? (only you or Louis can close issues for permission reasons)

deekerman commented

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

Author

Owner

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

@4n0nh4x0r
We are consolidating duplicate issues a bit to make issue management easier.
I think, we should track this issue in #2387 as there is no functional difference (maybe just small naming differences, but nothing that would require a different issue imo)
⇒ I am going to close this as a duplicate.

@CommanderStorm commented on GitHub (Dec 3, 2023): @4n0nh4x0r We are consolidating duplicate issues a bit to make issue management easier. I think, we should track this issue in #2387 as there is no functional difference (maybe just small naming differences, but nothing that would require a different issue imo) ⇒ I am going to close this as a duplicate.