Detection is not resolution: the gap that makes guards decorative
Every monitoring discussion quotes one number: how fast did we notice? The number that describes the damage is the second one - how long until the behaviour actually changed? For a trading guard, the honest version of that pair is often "200 milliseconds" and "fifteen minutes".
From the account's point of view, a guard that notices in 200ms and stops trading in 15 minutes does not exist. And the dashboard is green at every moment anyone looks at it, because "we detected it" is true.
Why the gap opens
Almost always architecturally. Detection writes a flag; a different component reads the flag and acts. Between them sits an interface that both sides assume behaves like a function call, when it actually behaves like a message: it can be delayed, read by nobody, or interpreted against a stale view of the world.
Anything that can be detected but not acted on is really two systems with a hopeful interface between them. Kubernetes calls one version of this "a dead node that keeps receiving traffic for thirteen minutes". Trading calls one version of it "the log says blocked, and the order path never reads the flag". Same shape.
Three habits that close it
- Measure both numbers, alert on the second. Time-to-detect is an engineering metric. Time-to-effect is the operational one. Teams that only page on the first look beautifully instrumented right up until the review.
- Make the detection path and the action path the same path. If a separate controller has to notice, then you have two definitions of "now" in the system, and they will disagree at exactly the wrong moment.
- Test the reaction, not the detection. Pull the input, kill the process, cut the feed - and time how long until the behaviour stops, not until the alert fires. Most test suites check the first half of the sentence and call it covered.
What this looks like in trading
| Signal you can observe | What it does not tell you |
|---|---|
| The guard evaluated and logged a breach | Whether the order path consulted the verdict |
| The alert fired within 200ms | Whether anything stopped |
| The state file was written | Whether it was written after the decision (a crash in between lets one order through) |
| The block flag is set | Whether it belongs to today, or to last Tuesday |
| The process is alive | Whether it is still connected to reality |
Each row is a case of a monitor reporting detection as if it were resolution. They are comfortable failures: everything you can see agrees with everything else you can see.
The two tests worth running this week
- Time the effect, not the alert. Trigger a limit breach and measure wall-clock time until the system is genuinely unable to place the next order. Write that number down; it is the real specification of your guard.
- Kill it with something open. Terminate the process mid-position, restart, and watch the next cycle. If the guard's verdict does not survive, then your protection has the same lifetime as an in-memory variable.
Neither test is sophisticated. Both require admitting that "we would notice" is not the same claim as "we would stop", and only the second one is what you actually sold yourself.
Related notes
- Your daily loss limit resets when MetaTrader restarts. Here is the fix.
- What a kill switch should actually do (and the four ways they fail)
- Silent failures in trading automation: the three that cost the most
- Which day is it? Broker time, host time, and the trading-day boundary
Get the guard
Free MT5 daily-loss guard, source included: https://xuks124.github.io/vigildesk/free.html
Risk disclosure
Algorithmic trading carries both technical and market risk. No tool eliminates the possibility of loss. Nothing on this page is investment advice, and no performance is implied or promised.