> ## Documentation Index > Fetch the complete documentation index at: https://uncoded.ch/docs/llms.txt > Use this file to discover all available pages before exploring further. # Triggers — The 4 Firing Modes > Triggers gate when a fired condition produces a signal. The 4 modes — once, once_per_bar, once_per_bar_close, once_per_minute — prevent the most common strategy bug: an oscillator stuck at threshold firing every tick. **Triggers are the firing-rate gating logic.** Without trigger gating, an "RSI \< 30" condition would fire every tick the condition holds — dozens of signals per minute on a stuck oscillator. Triggers prevent this by deciding *when* a fired condition produces a signal, not just whether it does. ## The 4 trigger modes | Mode | When it fires | Use for | | ------------------------ | -------------------------------- | ---------------------------------------------- | | **`once`** | Once for the entire strategy run | One-shot setups | | **`once_per_bar`** | At most once per candle | Resets eligibility per bar; can fire intra-bar | | **`once_per_bar_close`** | Only on bar-close | Most operators' default; clean and predictable | | **`once_per_minute`** | At most once per minute | High-frequency strategies with rate-limiting | ## `once_per_bar_close` — the recommended default **This is the trigger mode most operators should use almost always.** Here's why: it fires only when a candle closes, eliminating intra-bar noise. Each closed candle either fires the signal or doesn't — clean, predictable, no ambiguity. Mid-bar prices are noisy and can flip rapidly. A condition that's true at minute 3 of a 15-minute bar may be false by minute 14. If your trigger fires intra-bar, you've signaled on a state that didn't persist. Bar-close means the condition was true at the moment the bar ended. That's a stable, observable, replayable state. Backtesting traditionally evaluates at bar-close — that's when historical data is reliable. Live `once_per_bar_close` matches the backtest evaluation logic. Backtest agreement = live confidence. Other trigger modes can produce live behavior that diverges from backtests because backtests don't replay intra-bar mini-states. `once_per_bar_close` on `15m` candles fires at most 96 times per day (24 × 4 = 96 closes). Practical maximum. Most strategies fire on 5-15% of bars. Sane firing rates. ## `once_per_bar` — intra-bar firing with per-bar reset When the condition becomes true intra-bar, fire immediately. Reset firing eligibility on next bar's start. Use only if you specifically want intra-bar entry timing — e.g., capturing a fast move within a candle without waiting for close. Example: "buy when RSI dips below 25 — even if it bounces back before bar close." Some operators want this for fast bounces. Intra-bar conditions can flip rapidly. Firing on intra-bar state can produce trades on transient conditions that don't persist. Most operators avoid `once_per_bar` for this reason. Use only with deliberate intent. ## `once_per_minute` — rate-limiting for high-frequency Fires at most once per minute, regardless of bar boundaries. Useful for very-fast timeframe strategies (`1m`) where you want at most one signal per real minute, ignoring bar boundaries. Rare for unCoded modes — most operators run timeframes ≥ 15m. Easy to flood the SignalsBot if conditions hold for extended periods. RSI stuck below 30 for 60 minutes = 60 signals fired. SignalsBot has rate-limiting (`100/15min`), so floods get throttled — but you're in a misconfiguration scenario by then. ## `once` — one-shot setups Fires exactly once for the lifetime of the strategy run. After firing once, the trigger never fires again until the strategy is restarted. Niche use cases: * "Buy on the first oversold dip after I start the strategy." * "Set a one-time exit signal on a specific condition." Most strategies want repeatable signals, not one-shots. Use `once` deliberately for the rare one-shot need. Operators sometimes accidentally use `once` and wonder why the strategy never fires again after the first time. Always double-check the trigger mode. ## Common mistakes Most-frequent firing rate. Floods SignalsBot when conditions persist. **Fix**: default to `once_per_bar_close`. `once_per_bar` allows intra-bar firing. Different from `once_per_bar_close`. **Fix**: read trigger mode names carefully. `once_per_bar_close` is the bar-close-only variant. Entry strategies should be repeatable. `once` fires only the first time. **Fix**: use `once_per_bar_close` for entry strategies. If your entry strategy uses `once_per_bar_close` and your exit uses `once_per_minute`, you have asymmetric firing rates that can leave state in unexpected configurations. **Fix**: same trigger mode for paired entry/exit strategies (both `once_per_bar_close`). ## Best practices * ✅ **Default to `once_per_bar_close`** for almost every strategy. * ✅ **Match entry and exit trigger modes** — both `once_per_bar_close` typically. * ✅ **Avoid `once_per_minute`** unless you specifically want sub-bar rate-limiting. * ✅ **Use `once`** only for genuinely one-shot setups. * ✅ **Verify trigger choice in preview** — high firing rate is usually a wrong-trigger sign. * ✅ **Don't change triggers mid-validation** — settle on one for backtest, forward-test, and production. ## What's next The predicates that feed into triggers. The 136 indicators producing values for conditions. The 15 timeframes (which determine `once_per_bar_close` cadence). Where you set the trigger mode on each Trigger node.