@cryptotaxi247 / netdata-1 / commits / ca37fb53a

docs(health): clarify "special user of the cond operator" p2 (#19590)

Ilya Mashchenko committed Feb 7, 2025 at 13:38 UTC ca37fb53a783e3283f1fe920d89151799e682eb0
1 file changed +5 -8
src/health/REFERENCE.md
+5 -8
@@ -779,16 +779,13 @@ warn: $this > (($status >= $WARNING) ? (75) : (85))
779 crit: $this > (($status == $CRITICAL) ? (85) : (95))
780 ```
781
782 -| Alert State | Triggers At | Clears At | Explanation |
783 -|-------------|-------------|-----------|---------------------------------------------------------|
784 -| Warning | 85% CPU | 75% CPU | Once in warning state, requires a larger drop to clear |
785 -| Critical | 95% CPU | 85% CPU | Once in critical state, must drop back to warning level |
782 +| Alert State | Triggers At | Clears At | Explanation |
783 +|-------------|-------------|-----------|---------------------------------------------------------------------------|
784 +| Warning | 85% CPU | 75% CPU | Creates a 10% buffer - CPU must drop below 75% to clear a warning state |
785 +| Critical | 95% CPU | 85% CPU | Creates a 10% buffer - CPU must drop below 85% to return to warning state |
786
787 -This creates a buffer zone that prevents alert flapping. For example:
787
789 -- If CPU usage bounces between 80–90%, you'll get just one warning (when it first hits 85%)
790 -- The warning won't clear until the CPU drops well below the trigger point (75%)
791 -- The Same principle applies to critical alerts—they won't clear until the CPU drops significantly (85%)
788 +If CPU usage fluctuates between 80–90%, you'll receive just one initial warning, rather than constant notifications.
789
790 This approach gives you the best of both worlds: quick alerting when issues arise, but protection against notification spam when values hover near a threshold.
791