Acknowledge PROBE/NOTIFICATION

[mabed-fr]

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

• I checked and didn't find similar feature request

🏷️ Feature Request Type

API, New Notification, New Monitor, UI Feature, Other

🔖 Feature description

hello,
The notification functionality is changing a lot, especially with the possibility of repetition #1212

Would it be possible to add the 'ACK' functionality ?

This is a basic functionality of all monitoring tools which allows you to say that “the incident is taken care of”

In monitoring tools such as nagios or others, this complements the downtime (DT) functionality.

In practice this makes it possible to stop sending notifications and put away the incident, or for team work to indicate that the problem has been taken into account.

It is important to add that if the incident disappears the "ACK" must disappear

✔️ Solution

Exemple with centreon / nagios

https://docs.centreon.com/docs/alerts-notifications/acknowledge/

Another point of view --> https://www.site24x7.com/help/alarms.html#acknowledge-alarms

ACK in uptime KUMA

GUI/Frontend

• Added an Action --> "ACK" compatible with the check list
• Added ACK/not-ACK filter
• By default do not display ACK checks
• An ACK always has a comment attached
• ACK only possible on status DOWN
• ACK is not a status but a state like ACTIVE / PAUSED
• A user must be able to delete one or more ACKs manually

Backend:

• ACK should stop notification repetition
• ACK must be deleted automatically once the service is "UP"
• A user must be able to delete one or more ACKs manually manually

❓ Alternatives

No response

📝 Additional Context

No response

[CommanderStorm]

One of the reasons why your Issue has not got any comments is that it is quite unclear in what it proposes.
What do you mean by the 'ACK' functionality?

Another is that the docs you linked are only avaliable in french.
Please translate the relevant parts instead of linking to such documentation.

[mabed-fr]

Hello

This is a basic functionality of all monitoring tools which allows you to say that “the incident is taken care of”

In monitoring tools such as nagios or others, this complements the downtime (DT) functionality.

In practice this makes it possible to stop sending notifications and put away the incident, or for team work to indicate that the problem has been taken into account.

It is important to add that if the incident disappears the "ACK" must disappear

[mabed-fr]

@CommanderStorm is good ?

[mabed-fr]

ACK in uptime KUMA

GUI/Frontend

• Added an Action --> "ACK" compatible with the check list
• Added ACK/not-ACK filter
• By default do not display ACK checks
• An ACK always has a comment attached
• ACK only possible on status DOWN
• ACK is not a status but a state like ACTIVE / PAUSED
• A user must be able to delete one or more ACKs manually

Backend:

• ACK should stop notification repetition
• ACK must be deleted automatically once the service is "UP"
• A user must be able to delete one or more ACKs manually

[CommanderStorm]

Seems clearer to me now.
I don't quite get why a user must delete acknoleged downtime's.

If you'd like to implment such a feature, please have a look at our contribution guide

[mabed-fr]

I lacked clarity

The ACK should be deleted automatically when the service is up

[CommanderStorm]

If that is the case:
From an architecture perspective, I would suggest

• adding the ability to auto-disable maintenance periods (See Auto-disable maintenance after services are UP #3768) and
• adding the ability to add maintenance quickly (See Maintenance in one-click #2984)

[CommanderStorm]

I just found this issue which is a duplicate #2397

If you agree, could you please close this Issue, as duplicates only create immortal zombies and are really hard to issue-manage?
If not, what makes this issue unique enough to require an additional issue? (Could this be integrated into the issue linked above?) ^^

[mabed-fr]

I do not agree: The two features that you point out to me seem good but do not meet the request.

Here is more detail

Downtime / maintenance period: Downtime is a defined period during which a monitored element is not considered active or operational. It is often used when you know that your system or a specific element will be unavailable for a given reason, such as planned maintenance, updates, or repairs. During this period, alerts and notifications are typically not generated because the system recognizes that the unavailability is expected.

Acknowledgment: Acknowledgment is a mechanism that allows a monitoring operator to acknowledge a specific alert or issue, usually through manual action. This means that the operator has seen the alert and is aware of its existence. Acknowledgment can be used to indicate that the support team is aware of the problem and is working on it. The alert continues to be active but is marked as having been seen and addressed. Acknowledgment does not necessarily mean that the problem is resolved, only that it is being addressed.

In summary, downtime is used to schedule expected periods of unavailability, while acknowledgment is a manual action indicating the operator is aware of a specific alert. Both concepts contribute to improving alert management and responsiveness to issues in a monitoring system.

I hope it's clear to you, I know it's difficult to explain but being in the operational (ops) field it's obvious to me

[CommanderStorm]

So the first silences the alerts and the second silences the alerts?
Is there a functional difference I am not seeing or is this just naming?

[mabed-fr]

There is a functional difference that I tried to describe to you

#1989 (comment)

Exemple with centreon monitoring
ACK

https://docs.centreon.com/cloud/alerts-notifications/acknowledge/

Downtime / maintenance

https://docs.centreon.com/cloud/alerts-notifications/downtimes/

[CommanderStorm]

There is a functional difference that I tried to describe to you

What is the functional different between auto-resolving, easily created maintenance periods and acknowledgement?
As mentioned above: the effect of both (silencing alerts until the monitor is UP) looks to be the same to me.

In the comment you mentioned, you only go into the difference between scheduled maintenance periods and acknowledgement.

[mabed-fr]

After several rereadings during the day I came to the conclusion.

Maintenance in the literal sense of the term is known, where the ACK is a taking into account of an unforeseen incident the difference is perhaps not technical but etymological because yes the ACK and maintenance share similarities (between auto-resolving , easily created) but the ACK is not a maintenance but a consideration of an unforeseen incident

[mabed-fr]

I think that the development of a TECHNICAL table is required

Feature	Maintenance	ACK
Silencing the alert	Yes	Yes
Auto-resolving	optional	mandatory
easily created	optional	mandatory
Related comment	title + description	mandatory

[HolyFredy]

As I understand: from a technical perspective, it's the same as the auto-resolving and easily creating features.
But it should be named differently on the front-end to be able to distinguish them from one to another.

[mabed-fr]

Hello

What do you think @louislam ?

[CommanderStorm]

@chakflying
Do you think we should merge this issue into the following issues or keep this as a different issue:

• Auto-disable maintenance after services are UP #3768
• Maintenance in one-click #2984

[chakflying]

I think it's different enough that we can keep it separate.