mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 06:55:52 +03:00
[GH-ISSUE #2434] Error alerts do not trigger if a Warning alert is active #3433
Labels
No labels
In Process
bug
bug
dev-triage
documentation
duplicate
enhancement
fixed
good first issue
help wanted
integration
invalid
pull-request
question
requires agent update
security
ui tweak
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tacticalrmm#3433
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sebvonhelsinki on GitHub (Mar 12, 2026).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2434
Server Info (please complete the following information):
Installation Method:
--insecureflag at installAgent Info (please complete the following information):
Describe the bug
When a check changes from the "Warning" to the "Error" state, and Alerts are configured to trigger for "Warnings" and for "Errors", then no additional alert is triggered.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect that it triggers the alert action when the check enters the "error" state regardless of wheter a lower priority alert has been triggered before
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
@silversword411 commented on GitHub (Mar 12, 2026):
https://github.com/amidaware/tacticalrmm/issues/1291
@sebvonhelsinki commented on GitHub (Mar 13, 2026):
I made a new issue since the other one proposes a direct solution and was subsequently tagged as "enhancement". I consider the current behavior a bug (feature not working as expected) and fixing it not an enhancement (adding additional functionality), and I do not care about a specific "how", just that we do not have outages due configured checks not alerting us despite reaching an Error state.
Also the other issue was neither acted nor commented on for 3.5 years, so I considered it stale and unlikely to be picked up anytime soon.