[GH-ISSUE #333] Feature Request: remove "red" status of client when snoozing an issue #2155

Closed
opened 2026-03-14 02:47:52 +03:00 by kerem · 8 comments
Owner

Originally created by @manc74 on GitHub (Mar 18, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/333

Originally assigned to: @sadnub on GitHub.

Currently when an alert is snoozed for a period, the red status of the host still shows, as well as it appearing at thr top of the list.

Can we have the option to stop the highlighting of an item when it's snoozed?

Originally created by @manc74 on GitHub (Mar 18, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/333 Originally assigned to: @sadnub on GitHub. Currently when an alert is snoozed for a period, the red status of the host still shows, as well as it appearing at thr top of the list. Can we have the option to stop the highlighting of an item when it's snoozed?
kerem closed this issue 2026-03-14 02:47:58 +03:00
Author
Owner

@sadnub commented on GitHub (Mar 19, 2021):

That's a good idea! Will work on this

<!-- gh-comment-id:802930102 --> @sadnub commented on GitHub (Mar 19, 2021): That's a good idea! Will work on this
Author
Owner

@sadnub commented on GitHub (Mar 20, 2021):

I was checking into this a bit more and the snoozing of the alert actually just silences the notifications. The check/task is still continuing to run and will report the status regardless of being snoozed or not. This was by design.

You could exclude the agent from the alert template or just uncheck the alert boxes and it won't report as being down.

<!-- gh-comment-id:803478524 --> @sadnub commented on GitHub (Mar 20, 2021): I was checking into this a bit more and the snoozing of the alert actually just silences the notifications. The check/task is still continuing to run and will report the status regardless of being snoozed or not. This was by design. You could exclude the agent from the alert template or just uncheck the alert boxes and it won't report as being down.
Author
Owner

@manc74 commented on GitHub (Mar 20, 2021):

Yes I saw thats how it works. The current issue is that if a check looks at the event log for the last 24 hours, even when it's fixed there's no way to clear the issue unless you remove the check, this then means if the check fails again it won't trigger (and easy to forget to put the check back in place after 24 hours expires)

<!-- gh-comment-id:803484010 --> @manc74 commented on GitHub (Mar 20, 2021): Yes I saw thats how it works. The current issue is that if a check looks at the event log for the last 24 hours, even when it's fixed there's no way to clear the issue unless you remove the check, this then means if the check fails again it won't trigger (and easy to forget to put the check back in place after 24 hours expires)
Author
Owner

@dinger1986 commented on GitHub (Mar 21, 2021):

Can always change the checks to only look at 1 hour or something.

To be fair having written most of the event viewer checks I have defaulted to 24 hours but doesn't mean everyone needs to the checks can be customised.

<!-- gh-comment-id:803489900 --> @dinger1986 commented on GitHub (Mar 21, 2021): Can always change the checks to only look at 1 hour or something. To be fair having written most of the event viewer checks I have defaulted to 24 hours but doesn't mean everyone needs to the checks can be customised.
Author
Owner

@sadnub commented on GitHub (Mar 21, 2021):

I believe the resolve option should fix that. If the issue is still present it will open another alert thoughOn Mar 20, 2021 7:53 PM, manc74 @.***> wrote:
Yes I saw thats how it works. The current issue is that if a check looks at the event log for the last 24 hours, even when it's fixed there's no way to clear the issue unless you remove the check, this then means if the check fails again it won't trigger (and easy to forget to put the check back in place after 24 hours expires)

—You are receiving this because you were assigned.Reply to this email directly, view it on GitHub, or unsubscribe.

<!-- gh-comment-id:803489968 --> @sadnub commented on GitHub (Mar 21, 2021): I believe the resolve option should fix that. If the issue is still present it will open another alert thoughOn Mar 20, 2021 7:53 PM, manc74 ***@***.***> wrote: Yes I saw thats how it works. The current issue is that if a check looks at the event log for the last 24 hours, even when it's fixed there's no way to clear the issue unless you remove the check, this then means if the check fails again it won't trigger (and easy to forget to put the check back in place after 24 hours expires) —You are receiving this because you were assigned.Reply to this email directly, view it on GitHub, or unsubscribe.
Author
Owner

@sadnub commented on GitHub (Mar 21, 2021):

For this particular issue, it might make sense to adjust the check run interval to match how far the back the event log check searches. That way it won't trigger on the same event multiple times.

<!-- gh-comment-id:803660611 --> @sadnub commented on GitHub (Mar 21, 2021): For this particular issue, it might make sense to adjust the check run interval to match how far the back the event log check searches. That way it won't trigger on the same event multiple times.
Author
Owner

@dinger1986 commented on GitHub (Mar 21, 2021):

For bluescreens, viruses etc probably better to have it running regularly.

I was going to suggest that we could change the scripts to only check in the last hour or so however that would mean it would auto clear from the rmm and maybe not have been resolved.

Unless the rmm would keep it open until the issue is resolved which would need to be configurable because for example the speedtest script clears when it goes back over the threshold and that's good.

Another option would be that you snooze the issue and that automatically pauses that check for a day or whatever amount of time? So it doesn't show up red? Don't know if that's a headache though?

<!-- gh-comment-id:803662315 --> @dinger1986 commented on GitHub (Mar 21, 2021): For bluescreens, viruses etc probably better to have it running regularly. I was going to suggest that we could change the scripts to only check in the last hour or so however that would mean it would auto clear from the rmm and maybe not have been resolved. Unless the rmm would keep it open until the issue is resolved which would need to be configurable because for example the speedtest script clears when it goes back over the threshold and that's good. Another option would be that you snooze the issue and that automatically pauses that check for a day or whatever amount of time? So it doesn't show up red? Don't know if that's a headache though?
Author
Owner

@sadnub commented on GitHub (Apr 16, 2021):

I added a clear check status that will be in the next release. This might be a better option than snoozing

<!-- gh-comment-id:820863497 --> @sadnub commented on GitHub (Apr 16, 2021): I added a clear check status that will be in the next release. This might be a better option than snoozing
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/tacticalrmm#2155
No description provided.