The pre-live checklist for a Pine strategy

A strategy that backtests cleanly can still misbehave the moment its alerts start posting to a webhook. The failures are mostly plumbing: a payload that is not valid JSON, an alert that fires on every tick, a session guard that does not pin its clock to IST. Each one is cheap to catch before the first live order and expensive after.

This page is the checklist Sarathi's own house strategies go through. Work it top to bottom. Every row has a pass condition you can observe, not an opinion.

The checklist

The rest of this page walks through each row.

1. Compile on v6

Pine v6 changed several defaults that quietly alter a strategy's behaviour: implicit bool conversion is gone, and and or evaluate lazily, and timeframe strings such as "D" need a multiplier. TradingView publishes the full list in its migration guide. A v5 script that still runs is not a passed check; convert it, fix what the compiler flags, and re-run the backtest. If the trade list changed, find out why before moving on. The Studio writes v6 from the start, and this page covers the breaking items one by one.

2. Confirmed closes, not ticks

A strategy recalculates on every realtime update when calc_on_every_tick is true, which means an entry can appear mid-bar and disappear before the close. Historical bars never behave that way, so the backtest and the live chart stop describing the same thing. Set it false, set process_orders_on_close = true, and put barstate.isconfirmed in the entry condition.

//@version=6strategy("ORB 15m", overlay = true,     calc_on_every_tick = false,     process_orders_on_close = true,     commission_type = strategy.commission.cash_per_order,     commission_value = 350,     slippage = 2)
longSig = barstate.isconfirmed and close > orHigh + buffer

The house rule adds ₹350 per order and two ticks of slippage to every backtest. Neither number is a forecast; they are a stress test so a strategy that only works at zero cost fails in the editor rather than in an account.

3. Prove it does not repaint

Repainting has four common causes, and this page covers them. The one that survives most reviews is request.security() with barmerge.lookahead_on on an incomplete higher-timeframe bar, which lets a 15-minute script see today's daily close at 09:30. Use a [1] offset with lookahead_on, or completed prior-period values with lookahead_off and the one-period lag documented.

The test is mechanical. Leave the strategy on a live chart for a few sessions and export the trade list. Then reload the chart so every bar is historical and export again. The two lists should match trade for trade. TradingView's repainting guide explains what each mismatch usually means.

4. Alert frequency

For alert() calls the frequency is the freq argument in code, and a strategy without calc_on_every_tick fires at bar close whatever you pass. For alertcondition() alerts it is the dialog's Once Per Bar Close setting. "Every time" can post the same order several times while the bar is still forming. For alertcondition() the choice lives in the dialog, not in the script, so it is easy to forget when recreating an alert. The alert() versus alertcondition() page covers how alert_message rides on strategy.entry().

5 and 6. A payload that parses

The webhook receiver only sees the body TradingView posts. If it is valid JSON the request arrives with an application/json header; anything else is sent as text/plain, per TradingView's webhook documentation. Sarathi accepts both, but a body that was meant to be JSON and is not will be rejected with a 400 that echoes what was received.

Numbers are the usual culprit. str.format('{0}', x) groups thousands by default and emits 57,530; str.tostring(x) can carry floating-point noise. Give every number an explicit pattern: {0,number,#.##} or str.tostring(x, "#.##"). The webhook alerts page has the worked example.

The body the receiver expects to see:

{  "sym": "BANKNIFTY",  "side": "BUY",  "type": "ORB",  "price": 57530,  "sl": 57400,  "qty": 30,  "time": "2026-08-27T09:30:00+0530"}

Two more traps. A stop computed from na becomes the string NaN, which JSON does not allow; guard the division that produced it. And an exit order with no alert_message posts the unexpanded placeholder {{strategy.order.alert_message}}; Sarathi logs that as ignorable and does not raise a card. The full field list, aliases and error codes are on the webhook page and under /developers.

7. Session and square-off in IST

Without a timezone argument, hour(), minute() and time() use syminfo.timezone, the exchange timezone. For NSE and MCX that is already IST, but pass "Asia/Kolkata" explicitly so the script still reads correctly on a non-Indian symbol or a copied chart. Express both the last-entry cut-off and the flat-by time in minutes since midnight.

hh = hour(time, "Asia/Kolkata")mm = minute(time, "Asia/Kolkata")tMins    = hh * 60 + mmcanEnter = tMins < 14 * 60 + 30     // no new entries after 14:30isEOD    = tMins >= 15 * 60 + 15    // flat by 15:15

The NSE F&O page has the session strings for NSE and MCX and the reasoning behind a 14:30 cut-off on a 15:30 close.

8. Size and risk per trade

The order card shows entry, stop, quantity, risk in rupees and notional. Those numbers come from the payload, so the payload has to carry a quantity that is a whole number of lots for the instrument, and a stop that is on the correct side of the entry. Work out the rupee risk on the card before the first live session: stop distance in points times quantity. If that figure surprises you, fix the script, not the tap.

Sarathi adds one more knob at decision time. Confirm carries ½, 1× or 2× of the payload quantity, rounded to a whole number of lots for the instrument and never below one lot, so a ½ tap on a one-lot signal places one lot. The Telegram page has the full wording.

9. Paper trade first

The paper route is a broker adapter that fills at the price hint, records the fill and the slippage, and never touches an exchange. It is never metered. Run the strategy on paper until every branch has fired at least once: long, short, stop, target, square-off, and a card you deliberately let expire. Each of these lands in the journal with its route, side, quantity, entry, fill and IST timestamp, so you can compare against the backtest line by line. The paper route page lists what it does and does not simulate.

10. Read the journal after a week

After five sessions, filter the journal by strategy and count four things.

A strategy that passes all ten rows is not guaranteed to make money. It is guaranteed to post what you think it posts, when you think it posts it, at the size you intended, and that is what this checklist is for.

Try it in Sarathi

The Studio writes Pine v6 with the house header from row 2 already in place. Point the alert at your webhook, leave the account on the paper route, and every card that arrives in Telegram and on the web dashboard waits for your Confirm or Skip. Nothing is placed until you tap.