KPI Alert Rules Engine

Watching a KPI for "went above X", "crossed below Y", "dropped more than Z over the last N samples", or "hasn't moved in a while" usually means a scattered handful of ad-hoc if() checks duplicated across every reporting script that watches that metric, each one reimplementing its own edge-detection and history tracking slightly differently. KpiAlertRulesEngine turns that into a declarative rule instead. Seven rule types cover the common cases: ABOVE and BELOW (plain threshold), CROSS_ABOVE and CROSS_BELOW (edge-triggered, fires once on the crossing rather than every tick the value stays past the line), TREND_UP and TREND_DOWN (fires when the value has moved by more than a threshold over a lookback window of samples), and STAGNANT (fires when the value's range over a lookback window is under a threshold - useful for "this metric has gone quiet, check if the strategy stopped trading" style monitors). Each rule carries its own small ring-buffer history (KPI_MAX_HISTORY samples, default 64) so TREND_*/STAGNANT rules can look back without the caller maintaining a separate array. KpiEngine wraps a set of named rules so a monitoring script can register several rules once at startup and then feed each new metric value in by name, printing whatever message the rule returns. Notes and limitations - Each rule's history is a FIXED-size ring buffer of KPI_MAX_HISTORY (64) samples, and each engine holds a FIXED array of up to KPI_MAX_RULES (32) rules - both deliberate so the KpiRule/KpiEngine structs assign/copy safely by value like ordinary MQL4 variables. Raise either constant and recompile if a project genuinely needs more history depth or more simultaneous rules. lookback is silently clamped into [1, KPI_MAX_HISTORY]. - TREND_UP/TREND_DOWN/STAGNANT report "not enough history yet" (and do not trigger) until `lookback` samples have actually been fed - expect no alert from a freshly-initialised rule on its first few updates regardless of the data. - CROSS_ABOVE/CROSS_BELOW need a previous value to detect an edge, so the very first KpiFeed() call on a fresh rule can never trigger a cross, only ABOVE/BELOW/STAGNANT-style rules can fire on sample one. - KpiEngineFindByName() does a linear scan over registered rules - fine at the documented 32-rule cap, not intended for a much larger rule set. - This engine only classifies whether a rule's CONDITION is currently true (or just became true, for the CROSS_* rules) - it has no built-in alert suppression/cooldown. A caller wanting "only alert once per hour even if the condition stays true" needs to add that logic around KpiFeed()'s return value itself.

Script · MT5 · v1.0 · Free

Tags: Alerts · Trend · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria