[GH-ISSUE #184] Feature Request: Warning State for Monitors #2054

New issue

Closed

opened 2026-03-14 02:17:31 +03:00 by kerem · 5 comments

kerem commented

2026-03-14 02:17:31 +03:00

Owner

Originally created by @mfeuhrer on GitHub (Nov 19, 2020).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/184

Originally assigned to: @sadnub on GitHub.

It would be nice to have a Warning state for monitors, besides just pass/fail. A yellow condition can be useful for information that could be a problem, but isn't yet.

Would be very useful for memory/CPU checks as well as script results.

Originally created by @mfeuhrer on GitHub (Nov 19, 2020). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/184 Originally assigned to: @sadnub on GitHub. It would be nice to have a Warning state for monitors, besides just pass/fail. A yellow condition can be useful for information that could be a problem, but isn't yet. Would be very useful for memory/CPU checks as well as script results.

kerem closed this issue

2026-03-14 02:17:36 +03:00

kerem commented

2026-03-14 02:17:42 +03:00

Author

Owner

@wh1te909 commented on GitHub (Nov 19, 2020):

I could make the status Warning instead of Failing if the "number of consecutive failures before alert" is set to any number higher than 1 but less than the actual consecutive failure count, and have it change to Failing once that number is reached. Does that work?

Otherwise don't really see how to differentiate between warning or failing. Maybe for script checks if you return a custom return code in your script like 99 or something unique we can reserve that for a "Warning" status. Right now scripts pass if they return 0 and any other number will be a fail.

@wh1te909 commented on GitHub (Nov 19, 2020): I could make the status Warning instead of Failing if the "number of consecutive failures before alert" is set to any number higher than 1 but less than the actual consecutive failure count, and have it change to Failing once that number is reached. Does that work? Otherwise don't really see how to differentiate between warning or failing. Maybe for script checks if you return a custom return code in your script like 99 or something unique we can reserve that for a "Warning" status. Right now scripts pass if they return 0 and any other number will be a fail.

kerem commented

2026-03-14 02:17:48 +03:00

Author

Owner

@bradhawkins85 commented on GitHub (Nov 20, 2020):

what about two options, one for Warning Count and one for Failure Count?
I'm currently seeing MeshAgent.exe using >3GB of RAM at times so killing the agent brings everything back to normal. With a warning we could trigger a script to fix the problem (but not fire an email for example) then if that doesn't help send the email alert on failure for further investigation.

@bradhawkins85 commented on GitHub (Nov 20, 2020): what about two options, one for Warning Count and one for Failure Count? I'm currently seeing MeshAgent.exe using >3GB of RAM at times so killing the agent brings everything back to normal. With a warning we could trigger a script to fix the problem (but not fire an email for example) then if that doesn't help send the email alert on failure for further investigation.

kerem commented

2026-03-14 02:17:53 +03:00

Author

Owner

@mfeuhrer commented on GitHub (Nov 21, 2020):

Let's take the CPU item for example. My thought would be to have anything below 70% consumption be passing, 70-90% consumption warning, and 90-100% consumption be a failure. At least on resource monitors, being able to tie this to a numeric range or percentage would be great.

You're dead on with the script check idea. We can exit with just about any error code number. 0 for pass, 1 for fail, 2 for warning (or 99, or whatever works easiest).

@mfeuhrer commented on GitHub (Nov 21, 2020): Let's take the CPU item for example. My thought would be to have anything below 70% consumption be passing, 70-90% consumption warning, and 90-100% consumption be a failure. At least on resource monitors, being able to tie this to a numeric range or percentage would be great. You're dead on with the script check idea. We can exit with just about any error code number. 0 for pass, 1 for fail, 2 for warning (or 99, or whatever works easiest).

kerem commented

2026-03-14 02:17:58 +03:00

Author

Owner

@wh1te909 commented on GitHub (Feb 16, 2021):

released in 0.4.8

@wh1te909 commented on GitHub (Feb 16, 2021): released in 0.4.8

kerem commented

2026-03-14 02:18:03 +03:00

Author

Owner

@mfeuhrer commented on GitHub (Feb 18, 2021):