[GH-ISSUE #2434] Error alerts do not trigger if a Warning alert is active #3433

Open
opened 2026-03-14 07:19:39 +03:00 by kerem · 2 comments
Owner

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):

  • OS: [e.g. Ubuntu 20.04, Debian 10] Debian 12
  • Browser: [e.g. chrome, safari] Firefox
  • RMM Version (as shown in top left of web UI): 0.1.4

Installation Method:

  • Standard
  • Standard with --insecure flag at install
  • Docker

Agent Info (please complete the following information):

  • Agent version (as shown in the 'Summary' tab of the agent from web UI): 2.10.0
  • Agent OS: [e.g. Win 10 v2004, Server 2016] all of them

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:

  1. Define an Alerting Template that sends a mail when a Check fails with the "Warning" or "Error" (which is the default)
  2. Create a check that succeeds but can be brought into the "Warning" and "Error" state (i.e.: Diskspace check on a small partition)
  3. Bring the check into the "Warning" state (i.e. fill up the disk above the warning threshold)
  4. Bring the check from the "Warning" to the "Error" state without reaching the "success" or "Info" state in between (i.e. further fill up the disk above the error threshold)

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

  • Already asked on Discord two weeks ago but did not receive a response
  • For us this is a critical issue. We expected to be alerted on Errors and set up a process to immediately react to any Error alerts, while Warning alerts are handled with a lower priority. An Error state should not be made invisible to us by a lower priority alert.
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):** - OS: [e.g. Ubuntu 20.04, Debian 10] Debian 12 - Browser: [e.g. chrome, safari] Firefox - RMM Version (as shown in top left of web UI): 0.1.4 **Installation Method:** - [x] Standard - [ ] Standard with `--insecure` flag at install - [ ] Docker **Agent Info (please complete the following information):** - Agent version (as shown in the 'Summary' tab of the agent from web UI): 2.10.0 - Agent OS: [e.g. Win 10 v2004, Server 2016] all of them **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: 1. Define an Alerting Template that sends a mail when a Check fails with the "Warning" or "Error" (which is the default) 2. Create a check that succeeds but can be brought into the "Warning" and "Error" state (i.e.: Diskspace check on a small partition) 3. Bring the check into the "Warning" state (i.e. fill up the disk above the warning threshold) 4. Bring the check from the "Warning" to the "Error" state without reaching the "success" or "Info" state in between (i.e. further fill up the disk above the error threshold) **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** - Already asked on [Discord](https://discord.com/channels/736478043522072608/1006426744267477053/threads/1475439389118300192) two weeks ago but did not receive a response - For us this is a critical issue. We expected to be alerted on Errors and set up a process to immediately react to any Error alerts, while Warning alerts are handled with a lower priority. An Error state should not be made invisible to us by a lower priority alert.
Author
Owner

@silversword411 commented on GitHub (Mar 12, 2026):

https://github.com/amidaware/tacticalrmm/issues/1291

<!-- gh-comment-id:4048622304 --> @silversword411 commented on GitHub (Mar 12, 2026): https://github.com/amidaware/tacticalrmm/issues/1291
Author
Owner

@sebvonhelsinki commented on GitHub (Mar 13, 2026):

#1291

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.

<!-- gh-comment-id:4053602295 --> @sebvonhelsinki commented on GitHub (Mar 13, 2026): > [#1291](https://github.com/amidaware/tacticalrmm/issues/1291) 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.
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#3433
No description provided.