A crypto workflow candle-close trigger should start an evaluation only after the selected market's candle is confirmed complete. Bind the run to that candle's identity and saved inputs, then apply separate signal, freshness and risk checks. A clock reaching the interval boundary does not prove that final candle data arrived, and a confirmed close does not guarantee an order or fill.
This guide is about turning a completed bar into a reproducible workflow run. Its event records and acceptance tests are a general design worksheet, not a claim that every platform exposes these settings.
The trigger schedules a question; the rules answer it
Separate three stages: the candle becomes eligible for evaluation, the strategy decides whether its condition is true, and the execution path decides whether action remains permitted. A workflow can correctly start every five minutes and correctly place no trades.
That distinction prevents a common configuration error: treating “candle closed” as the entry condition. A close is an observation boundary. It says nothing by itself about direction, position size, available balance or existing exposure.
Write whether the downstream rule may act again while its condition remains true. A workflow can evaluate every close while permitting only one open position. That position-state check must still run on the next candle; the trigger schedule cannot enforce it by itself.
Confirm the bar using the source's semantics
A stream may publish many updates for one candle. Binance Spot's kline payload includes the interval, opening time, closing time and x, a Boolean indicating whether the kline is closed. The c price appears in the payload while x can still be false. A field named close price therefore does not establish finality on its own. Use the documented completion flag for this source. Binance Spot candlestick stream specification.
A scheduler that wakes at 12:05:00 can request or inspect data, but it must still establish which bar it received and whether it is complete. Adding an arbitrary sleep may hide the issue during normal conditions and fail when delivery takes longer. Define a bounded wait and an explicit missing-data outcome instead.
TradingView has different terminology. For Pine alert() calls, alert.freq_once_per_bar permits the first qualifying call during a realtime bar. alert.freq_once_per_bar_close requires the call to execute on that bar's closing iteration. Earlier truth that disappears before the close is insufficient. TradingView alert frequency documentation.
These examples explain two sources; they do not establish the protocol for another venue or contract type. Identify the exact channel and product before mapping its fields.
Write a candle-to-run contract
Before testing, fill out this worksheet for one workflow version. Record it with the run so a later configuration change does not rewrite the explanation of an earlier decision.
| Item | Example specification | What it prevents |
|---|---|---|
| Market identity | Venue A, BTC/USDT spot, ordinary trade-price candles | Mixing a perpetual, mark price or another venue into the signal |
| Interval and anchor | Five-minute bars on UTC boundaries | Evaluating a differently aligned series |
| Completion evidence | Provider's documented closed state | Treating a live update as final |
| Candle identity | Market, interval, anchor and source opening timestamp | Confusing arrival time with the bar being evaluated |
| Input boundary | Saved candle and required preceding closed bars | A queued run silently reading a later candle |
| Lateness policy | Example: accept only within ten seconds of the boundary | Executing an old signal after a long interruption |
| Overlap policy | Serialize decisions for this strategy and market | Two runs using the same old position state |
| Missing input outcome | Record a skipped evaluation and its reason | Converting unavailable data into a false signal |
The ten-second limit is invented for illustration, not a recommended threshold or KLINEO default. Pick a limit that matches the strategy's assumptions, then test it. Use the source's actual timestamp conventions; do not assume its closing timestamp equals the next opening timestamp.
For general timestamp and input-readiness checks, use the market-data freshness guide. Here, those checks serve a narrower purpose: deciding whether one particular closed candle may start a run.
A delayed five-minute close, step by step
Consider a hypothetical workflow evaluating the candle opening at 12:00 UTC and ending at the 12:05 boundary. It accepts confirmed data within ten seconds and evaluates the condition “close above 250.” All prices, times and policies below are illustrative.
| Observation | Local time UTC | Workflow outcome |
|---|---|---|
| Partial candle shows price 251 | 12:04:58.000 | No close-triggered evaluation |
| Local timer reaches the boundary | 12:05:00.000 | Wait for completion evidence |
| Confirmed candle arrives with final close 249 | 12:05:02.400 | Save this candle and queue its evaluation |
| Worker starts the queued run | 12:05:04.000 | Evaluate saved close 249; entry condition is false |
| Same confirmed candle is observed again | 12:05:05.000 | Recognize the same candle; do not create another evaluation |
Receipt is 2.4 seconds after the boundary. Queue waiting adds 1.6 seconds, making the start four seconds after the boundary. The partial price of 251 never becomes an entry signal under this close-based rule. The worker must not substitute the new 12:05 candle's live price when it eventually starts.
If the confirmed candle instead first arrives at 12:05:14, this example's lateness policy rejects it for a new entry. Keep the candle for analysis and record the missed evaluation. Backfilling a historical bar and deciding to trade it now are separate choices.
Duplicate detection in this table concerns candle admission only. It does not settle whether a timed-out order reached the exchange. That later uncertainty requires order reconciliation.
The workflow idempotency guide carries a stable decision identity through downstream actions and recovery. If the candle instead arrives through a chart alert, webhook replay protection adds authentication, event-age and duplicate checks at that delivery boundary.
A closed trigger cannot finalize every downstream input
A five-minute close does not confirm a still-forming hourly filter. If the workflow evaluates at 12:05, it must specify which completed hourly candle is allowed, rather than silently using the hour that opened at 12:00. The multiple-timeframe analysis guide explains how to maintain that as-of boundary.
In Pine, barstate.isconfirmed is true on the closing update of a realtime bar, but TradingView specifically says it does not work when used inside request.security(). Do not treat a chart-timeframe confirmation test as a universal fix for higher-timeframe data. TradingView bar-state documentation.
Another edge case is an old alert configuration. TradingView saves the script, inputs, symbol and timeframe when an alert is created; editing the chart later does not update that running alert. Recreate it when the intended context changes and verify the received payload. TradingView running-alert context.
Test the trigger without rewarding extra orders
Use a paper environment to inject a partial bar, a normal close, a duplicate, a late close, a missing lookback bar and a restart with an older close still queued. Add a worker delay that crosses into the next interval. For each case, specify the expected candle identity, number of admitted evaluations and skip reason before running it.
Check results against those expectations, not against whether a trade happened. A healthy failure test may produce zero orders. The paper-trading validation guide covers the wider acceptance record, including the limits of simulated fills.
KLINEO's AI Agents overview describes workflows with Candle Close triggers and paper testing. KLINEO supports Candle Close intervals from 1m to 1D, and live workflow execution passes through the Risk Governor. The detailed admission worksheet here remains an evaluation aid: verify actual behavior and available settings in your environment before relying on them.
This AI-assisted article follows the editorial policy. Sources were reviewed on October 23, 2026. The worked timeline tests event handling; it is not a latency measurement, backtest result or return forecast.