Engineering note · Alert release checks
Changed Your Pine Script? Check Which Version Your Alert Runs
You change a Pine script input. The chart now looks right, but the next alert still follows the old rule. Before changing the signal logic again, compare the saved script, the chart instance and the running alert. They are three separate things to verify.
- 01Identify the release
- 02Inspect the active alert
- 03Replace the old instance
- 04Read the resulting message
A chart update is not an alert update
TradingView documents that a script alert retains the script, inputs, main symbol and timeframe from its creation. Later chart changes do not update that running copy. To use a changed context, recreate the alert from that context. See the official alert reference below.
That explains one possible mismatch, not every missed or unexpected alert. First establish which alert produced the message. Two similarly named instances can make a correct new setup look broken if the old one still sends notifications.
Keep a short release record: source revision, selected input values, full symbol, timeframe, alert condition and creation time. Save it beside the reproduction steps. A screenshot of a chart with a marker is not enough to identify the running configuration.
Trace one message before changing code
Choose a single unexpected notification. Retain its timestamp and body, then find the corresponding entry in the alert log. Compare its originating alert with the release record. If a bridge received the message, retain that receipt separately from any order outcome.
Check the selected event type too. TradingView distinguishes script alert calls from strategy order-fill events. Selecting both can produce different messages for different events. An emulator fill notification does not prove that a separate broker account filled an order.
Ask a precise question at each boundary: was the wrong event emitted, was the right event formatted incorrectly, or did a downstream receiver interpret it differently? Fixing those three problems requires different evidence. Keep receiver tokens and account details out of shared screenshots.
- Script record: revision and intended input set.
- Alert record: origin, condition, creation time and enabled state.
- Message record: event time, body and receiver acknowledgement.
- Execution record, if applicable: separate order identity and verified outcome.
Make replacement a controlled handoff
Before replacing an alert, record what the old instance is allowed to do and what will happen during the change. For an execution route, use an isolated test receiver or demo environment for the first verification. Decide how pending signals and open positions are handled before changing anything that can submit orders.
Load the intended source and settings, retire the superseded alert, then create the replacement. Give it a name that identifies the release. Verify its enabled state and routing. Avoid leaving old and new instances able to issue the same command unless that overlap is explicitly designed and tested.
A useful optional design is a release identifier in the message, where the script and receiver support it. This is a diagnostic field, not a replacement for event identity. Two deliveries from the same release can still refer to the same event; a receiver needs its own duplicate policy.
Verify behavior, not just the Save button
Write one qualifying event and one non-qualifying event into the test brief. Specify the expected message and the timing rule. TradingView script alerts trigger on realtime bars, so historical markers alone are not proof of a running notification path.
Keep the result at its actual evidence level. A correctly configured replacement that has not yet encountered its qualifying event is configured, but its output remains unverified. A received test message proves receipt, not trading performance or correct handling of every later event.
For a repair request, provide authorized source, the two configuration records and one redacted message example. State what should differ after the change. That gives a developer a bounded problem instead of a request to make all alerts reliable.
Three acceptance checks
Proposed tests, not executed customer results. Record actual outcomes separately.
Changed settings
Input: Create a replacement from the reviewed source and input set in an isolated test route.
Expected: The active alert matches the release record. A qualifying realtime event produces the expected message when observed; until then, output verification remains pending.
Condition is absent
Input: Observe a realtime interval where the frozen condition does not qualify.
Expected: No signal message is emitted for that condition. The observation interval and relevant inputs are retained.
Old and new instances
Input: Inspect the alert inventory after the replacement and trace the next qualifying event.
Expected: The retired instance cannot send another command. Every observed message has an identified origin; receipt and execution are reported separately.