barstate.isconfirmed is a Pine Script boolean that is true on every historical bar and on the closing update of a realtime bar. Adding it to a condition postpones that condition until the chart bar is confirmed. For bar-close alerts, the alert must also be configured to trigger from the intended event. Confirmation applies to the chart bar; it does not establish webhook delivery or a broker fill.
barstate.isconfirmed at a glance
As of 25 September 2026, TradingView documents the following bar-state variables.[1] This table describes the states an indicator can observe; a strategy's calculation settings determine which updates its code actually sees.
Scroll horizontally to read every column.
| Variable | On historical bars | On a realtime bar |
|---|---|---|
barstate.isconfirmed |
True | True on the closing update |
barstate.isrealtime |
False | True on its updates, including the closing update |
barstate.islast |
True only if the bar is the chart's last bar | True while it is the chart's last bar |
barstate.isnew |
True | True on the first update |
Each bar-state name is a built-in boolean variable, not a function: there are no parentheses. The Pine Script library explains how the same script runs across historical and realtime data.
What does confirmation mean for a condition?
Confirmed chart-bar condition = condition is true AND barstate.isconfirmed is true
A realtime indicator recalculates when new price or volume data arrives. Its close is then the latest price, not yet the final closing price. The current high, low and other calculations can also change.[2]
Before recalculating, Pine normally rolls temporary state back to the last committed state. The script then evaluates the new update. Plots or conditions that existed briefly can disappear from the finished bar, while an alert already triggered remains in the alert log.[2][5]
The expression above asks whether the condition is true at confirmation. It does not remember that the condition was true earlier. Remembering an intrabar event and reporting it later is a different rule and requires separately defined state.
Worked example: a condition appears, then disappears
Illustrative prices, not a trading recommendation. A bar opens at 100. An indicator checks close > open. Consider these three updates after the opening update:
| Update | Latest price and comparison | Confirmed condition |
|---|---|---|
| During the bar | 99 > 100 is false | False: the bar is still open |
| Later during the bar | 101 > 100 is true | False: the bar is still open |
| Closing update | 98 > 100 is false | False: the bar is confirmed but the condition failed |
An unconfirmed once-per-bar alert could fire at 101. A closing-update alert based on the current comparison does not fire at 98. If the final price were 102 instead, both the comparison and barstate.isconfirmed would be true at the close.
The historical bar retains the final prices. It does not reconstruct every intermediate true-or-false result that the realtime indicator observed. That explains how an alert can exist without a matching final chart marker.[2]
How do you write a Pine Script bar-close alert?
For alert(), use the frequency argument alert.freq_once_per_bar_close. TradingView requires the call to execute during the bar's closing iteration. The frequency does not schedule a call that executed only earlier in the bar.[3]
Illustrative sketch; not compiled or tested. Paste into the TradingView Pine Editor. The comparison is a timing demonstration, and the message is a notification rather than an order instruction. The plot shows 1 for a confirmed true condition and 0 otherwise.
//@version=6
indicator("Closing update example")
condition = close > open
eligible = condition and barstate.isconfirmed
plot(eligible ? 1 : 0, "Confirmed condition")
if eligible
alert("Bar closed above its open", alert.freq_once_per_bar_close)
The confirmation check also governs the plot. The frequency argument governs alert timing. Pine Script v6 documents the indicator(), plot() and alert() calls used here.[7]
- Add the indicator to the chart after reviewing its code and inputs.
- Create a TradingView alert on that indicator and select “Any alert() function call”. The message and frequency come from the call.[3]
- Inspect the alert log when a realtime bar closes. A historical plotted 1 is not a sent alert.
An indicator using alertcondition() takes a different route: select the named condition and set Once Per Bar Close in the alert dialog. alertcondition() has no frequency argument.[3] The alertcondition() versus alert() comparison covers both routes.
How are isrealtime, islast and isnew different?
isrealtime identifies realtime updates. It is also true on the closing update, when isconfirmed becomes true. The variables are not opposites. Adding isrealtime to a historical diagnostic plot removes its historical cases.[1]
islast identifies chart position. It is useful for updating a display on the chart's last bar. It does not mean that bar has closed. On a closed market, the chart's last bar can be historical, last and confirmed at the same time.[1]
isnew identifies the first realtime update, and all historical bars. Using it as a bar-close test reverses the intended realtime timing. A normal realtime bar with multiple updates cannot satisfy “first update only” and “closing update only” on the same execution.[1]
Does barstate.isconfirmed prevent every kind of repainting?
No. Chart-bar confirmation resolves uncertainty about that bar's final values. It does not fix an expression that uses future data in history or data still developing on another timeframe.
For example, a 15-minute bar can close while its enclosing hourly bar remains open. The request.security() guide explains TradingView's previous-higher-timeframe-bar pattern. TradingView also states that barstate.isconfirmed does not work inside a request.security() call.[1][4]
Pivot confirmation has another delay: a pivot needs its right-hand bars before detection. Waiting for the original pivot bar's close cannot supply bars that have not happened yet. Separately, TradingView warns that incorrect higher-timeframe requests and intrabar strategy calculations can cause alert discrepancies.[5]
What changes when the script is a strategy?
By default, strategies calculate at realtime bar close. Enabling calc_on_every_tick lets them calculate on realtime updates; those intrabar calculations do not have the same information after reload.[3][5] A bar-state variable reports the current execution's state. It does not itself cause an extra execution.
Order fill alerts are separate from alert() calls. They respond to fills in TradingView's broker emulator and are not governed by an alert() frequency argument.[3] The strategy entry and exit reference separates order creation from simulated filling.
What should a PineConnector workflow verify after bar close?
A confirmed condition is only the first checkpoint. Record the alert trigger, webhook delivery, PineConnector processing and the EA's order request separately. Then check the broker's actual order, deal and position.[8] PineConnector's demo test guide checks the TradingView log, Bridge result and broker account independently.[6]
Once per bar is not once per position. A condition can remain true across successive bars and generate another eligible alert on each. Specify any repeat-signal rule separately. After editing the script or inputs, recreate the affected alert because the existing alert keeps its saved snapshot.[3][5]
Frequently asked questions
What does barstate.isconfirmed mean?
barstate.isconfirmed is true on all historical bars and on the closing update of a realtime bar. Combining it with a condition means the condition must be true when that chart bar is confirmed. The variable does not verify higher-timeframe data, webhook delivery or the outcome of a broker order.
How do I make a Pine Script alert fire on bar close?
For alert(), use alert.freq_once_per_bar_close and ensure the call executes on the realtime bar's closing update. For an indicator's alertcondition(), select its named condition and Once Per Bar Close in TradingView's alert dialog. Code defines eligible events; a user still creates the running alert.
Can barstate.isrealtime and barstate.isconfirmed both be true?
Yes. On a realtime bar's closing update, barstate.isrealtime remains true and barstate.isconfirmed is true too. Realtime identifies the execution context, while confirmed identifies whether the bar's values are final. Historical bars are confirmed but do not have a realtime state during historical calculation.
Will a bar-close alert remember a condition that was true earlier?
Not by frequency alone. alert.freq_once_per_bar_close only permits a call made on the closing update to trigger. If the condition becomes false before the close and the call no longer executes, no alert fires from that call. Remembering an earlier intrabar event is a separate state-handling rule.
Reviewed 25 September 2026. Facts were checked against the linked sources on that date. Nothing in this article was tested on a trading account and no code was compiled.
Related reading
- Pine Script guide and function library
- alertcondition() versus alert()
- Higher-timeframe data and lookahead
- Strategy orders and order fill alerts
Sources
- TradingView – Bar states, accessed 25 September 2026.
- TradingView – Execution model, accessed 25 September 2026.
- TradingView – Alerts, accessed 25 September 2026.
- TradingView – Other timeframes and data, accessed 25 September 2026.
- TradingView – Pine Script FAQ: Alerts, accessed 25 September 2026.
- PineConnector – Test your setup, accessed 25 September 2026.
- TradingView – Pine Script v6 Reference Manual, accessed 25 September 2026.
- MetaQuotes – Basic principles: orders, deals and positions, accessed 25 September 2026.
PineConnector executes the instructions you send it. It does not select trades, manage money, or hold funds. Trading carries risk, and past performance of any strategy does not indicate future results.
