Why Your Breakout Alert Keeps Firing on a Wick (and How to Stop It)

You drew the level carefully. The alert fired. By the time you looked, price was back inside the range and the candle had closed nowhere near your line. This is not bad luck, and it is not the market hunting you personally. It is three specific pieces of missing logic.

Bug one: the trigger reads a bar that has not finished

A forming candle is a rumour. Its high and low are the extremes reached so far, and both can be taken back before it closes. If your trigger evaluates the live price, or reads the newest bar including the one still forming, then every wick that pokes through your level is a fire.

The fix is to judge closed bars only. In chartTrigger this is the confirm on close setting: with it on, a price trigger reads a series with the forming bar dropped, so a wick through a level cannot fire it. The level has to be beaten by a bar that actually closed.

The cost, stated plainly

Close confirmation is not free. On a 4-hour chart you may be waiting hours after the level was breached, and a genuine fast move will be well past your entry by the time the bar closes. This is a real trade-off:

There is no universally right answer. There is only choosing on purpose rather than discovering your default by being burned.

Bug two: no tolerance band

"Price beyond the level" with no margin means a single tick counts. So does a spread widening at the session roll, a thin-liquidity print at the open, and a feed glitch. You get alerts that are technically correct and practically useless, and within a fortnight you stop reading them — which is worse than having no alerts, because now you trust the wrong thing.

A tolerance band says how far past the line counts as past the line. Express it in points, pips or a percentage, and size it against the instrument's typical noise rather than against what looks tidy on screen. If a symbol's spread alone is 20 points, a 5-point band is decoration.

Bug three: confusing a state with an event

This one produces the most confusing symptom of all: the alert fires the instant you arm it, on nothing.

The cause is a condition written as a state — "price is below the trendline" — rather than as an event. If price has been under that line for three days, the condition is true at the moment you arm the rule, and a naive engine reads true and fires.

A break is a crossing: price was on one side, and then moved beyond the other by more than the tolerance. chartTrigger's evaluator treats a retest exactly that way — a close on one side followed by movement past the other by the band — which is precisely why the first touch of an untested level does not count as a retest. And a rule re-armed while its condition is still true starts closed, so an existing state is never mistaken for a fresh trigger.

The fourth one: restarts that reset everything

Worth knowing because it bites silently. Most rule engines keep "has this fired?" in memory. Restart the process — a deploy, a crash, a VPS reboot — and every armed rule can fire again immediately. Cooldowns lapse. Maximum-fire caps reset. A once-per-bar rule fires twice on the same bar.

chartTrigger stamps a rule when it is armed and replays the fires recorded since that arming back into memory on startup, so caps and cooldowns hold across a restart. It is the kind of thing nobody asks about in advance and everyone notices afterwards.

Tuning a noisy alert, practically

1. Check the trigger is a crossing. If it fires at arming time, it is a state. Fix this first; nothing else matters until it is right.
2. Widen the band until the grazes stop. Start deliberately too wide and tighten.
3. Turn on close confirmation on anything M15 and above and see whether you actually miss the moves you thought you would.
4. Add a cooldown so one chop session cannot produce eleven messages.
5. Cap the fires per arming so a runaway rule has a ceiling.
6. Run it in Ghost Mode for a fortnight and read the record before trusting it with an order.

Then prove it on history

Once the logic is right, the Proving Ground shows how the rule would have behaved over past bars, using the same evaluator as the live engine and the spread and slippage you state. It is a historical simulation — its job is exposing broken logic, not predicting anything. Comparing the same rule with close confirmation on and off over the same window is the fastest way to settle that argument for your own instrument and timeframe.

Common questions

What does "confirm on close" mean?

The trigger evaluates only bars that have finished. The bar still forming is dropped, so a wick through your level cannot fire the rule — the bar has to close beyond it.

Why does my alert fire immediately when I arm it?

Because the condition describes a state that is already true, rather than a crossing. Rewrite it as an event: price closed on one side and then moved beyond the other by the tolerance.

Should I always use close confirmation?

No. It filters fakeouts at the cost of speed. It suits higher timeframes and swing levels; it is often wrong for scalping, where being late costs more than being wrong.

Risk note. This article is educational material about how chartTrigger works. It is not investment advice, not a recommendation to trade any instrument, and nothing here forecasts results. Trading leveraged products carries a high risk of loss. Any historical simulation referred to is exactly that — a run over past bars under stated spread and slippage assumptions, not an indication of future performance.