[GH-ISSUE #1849] [BUG]: Resolved Alerts are triggered after exiting maintenance mode #3099

New issue

Closed

opened 2026-03-14 06:32:49 +03:00 by kerem · 3 comments

kerem commented

2026-03-14 06:32:49 +03:00

Owner

Originally created by @joeldeteves on GitHub (Apr 18, 2024).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1849

Server Info (please complete the following information):

OS: Debian (Kubernetes Node)
Browser: Chrome / Edge
RMM Version (as shown in top left of web UI): v0.18.2

Installation Method:

Standard
Standard with --insecure flag at install
[ x ] Docker

Agent Info (please complete the following information):

Agent version (as shown in the 'Summary' tab of the agent from web UI): v2.7.0
Agent OS: [e.g. Win 10 v2004, Server 2016] Windows Server 2019 Standard

Describe the bug
It seems like whenever we turn off maintenance mode we get a ton of “resolved” alerts.

We don’t get alerted during the window which is correct, but we get alerted for service restorations after the window is over, even if those services were resolved during the window.

This has been going on for as long as I remember, I just haven't had time to open an issue for it. I am confident every version of Tactical has done this, at least in our specific environment.

To Reproduce
Steps to reproduce the behavior:

Put a client in maintenance mode
Trigger a reboot
Exit maintenance mode (can be an hour later, it still does it)
"Service Check: Resolved" gets triggered even though the service was started long before exiting maintenance mode

Expected behavior
Maintenance mode should not trigger Resolved alerts after exiting maintenance mode.

Screenshots
N/A

Additional context
@wh1te909 is familiar with our environment. It is technically "unsupported" but nonetheless if it's something on our side, just need to know what the cause is so we can address and resolve accordingly. I am filing it as a bug report for now per conversation on Discord.

Originally created by @joeldeteves on GitHub (Apr 18, 2024). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1849 **Server Info (please complete the following information):** - OS: Debian (Kubernetes Node) - Browser: Chrome / Edge - RMM Version (as shown in top left of web UI): v0.18.2 **Installation Method:** - [ ] Standard - [ ] Standard with `--insecure` flag at install - [ x ] Docker **Agent Info (please complete the following information):** - Agent version (as shown in the 'Summary' tab of the agent from web UI): v2.7.0 - Agent OS: [e.g. Win 10 v2004, Server 2016] Windows Server 2019 Standard **Describe the bug** It seems like whenever we turn off maintenance mode we get a ton of “resolved” alerts. We don’t get alerted during the window which is correct, but we get alerted for service restorations after the window is over, even if those services were resolved during the window. This has been going on for as long as I remember, I just haven't had time to open an issue for it. I am confident every version of Tactical has done this, at least in our specific environment. **To Reproduce** Steps to reproduce the behavior: 1. Put a client in maintenance mode 2. Trigger a reboot 3. Exit maintenance mode (can be an hour later, it still does it) 4. "Service Check: Resolved" gets triggered even though the service was started long before exiting maintenance mode **Expected behavior** Maintenance mode should not trigger Resolved alerts after exiting maintenance mode. **Screenshots** N/A **Additional context** @wh1te909 is familiar with our environment. It is technically "unsupported" but nonetheless if it's something on our side, just need to know what the cause is so we can address and resolve accordingly. I am filing it as a bug report for now per conversation on Discord.

kerem closed this issue

2026-03-14 06:32:55 +03:00

kerem commented

2026-03-14 06:33:00 +03:00

Author

Owner

@wh1te909 commented on GitHub (Apr 18, 2024):

can you paste screenshots of your alert policy settings just so I make sure I am replicating the issue properly

@wh1te909 commented on GitHub (Apr 18, 2024): can you paste screenshots of your alert policy settings just so I make sure I am replicating the issue properly

kerem commented

2026-03-14 06:33:05 +03:00

Author

Owner

@joeldeteves commented on GitHub (Apr 19, 2024):

Here you go:

@joeldeteves commented on GitHub (Apr 19, 2024): Here you go: ![trmm-alert-actions](https://github.com/amidaware/tacticalrmm/assets/33190570/2086b178-12dc-4bf9-b3f9-c28381bb53ff) ![trmm-agent-overdue-settings](https://github.com/amidaware/tacticalrmm/assets/33190570/561ebe87-4091-462d-8051-10a2f19e8f82) ![trmm-check-settings](https://github.com/amidaware/tacticalrmm/assets/33190570/420271f9-01cc-48f8-9a55-08f87db471b3)

kerem commented

2026-03-14 06:33:11 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jun 7, 2024):

Fixed in https://github.com/amidaware/tacticalrmm/pull/1823/commits/e6225ad2419bc93db45e9f50325cd46a3f89b2e3 will be in next release

@wh1te909 commented on GitHub (Jun 7, 2024): Fixed in https://github.com/amidaware/tacticalrmm/pull/1823/commits/e6225ad2419bc93db45e9f50325cd46a3f89b2e3 will be in next release