TradingView Alert Automation (Excel, Interactive Brokers, Options)

Introduction
A TradingView strategy that works on the chart is only half a system. The other half is getting each signal somewhere useful, reliably, every time: to a sheet your team watches, or to a broker that places the order.
This guide covers both. Use case A sends signals into a shared Excel file that stays open all day. Use case B executes them as options orders on Interactive Brokers, including splitting one trade across several accounts. Both share one foundation: a webhook receiver that never loses a signal and never acts on one twice.
1. What TradingView alerts can and cannot do
TradingView alerts run 24x7 on TradingView's servers and do not need you to be logged in, so your chart does not need to be open. A webhook alert sends a POST request to a URL you choose every time the alert fires. That POST is the hook everything in this guide builds on.
A few limits shape the design:
Plan and security. Webhooks need two-factor authentication and a paid plan; the free Basic plan cannot send them.
Network rules. TradingView accepts only ports 80 and 443 and cancels requests that take longer than three seconds. Your receiver must answer fast and do the real work afterwards.
Alert counts and expiry vary by plan. For a 500-stock watchlist, check how many active alerts your plan allows and whether they expire.
The broker panel is manual. TradingView's Interactive Brokers panel supports manual trading only; strategy alerts cannot execute through it. Automating IBKR needs a webhook receiver and the IBKR API.
2. Building a reliable webhook receiver
The receiver is a small always-on service with an HTTPS endpoint. It has four jobs: accept quickly, verify the sender, block duplicates, and hand the signal on.
Design the alert message once
Send JSON with everything the receiver needs, built from TradingView placeholders:
{ "secret": "REPLACE_WITH_SHARED_SECRET", "strategy": "nifty500-trend", "symbol": "{{ticker}}", "exchange": "{{exchange}}", "action": "{{strategy.order.action}}", "price": "{{close}}", "bar_time": "{{time}}", "fired_at": "{{timenow}}", "interval": "{{interval}}" } |
Accept, then process
Return HTTP 200 immediately and put the message on an internal queue. Excel updates and broker calls happen after the response, well inside TradingView's three-second window.
Verify the sender
Use HTTPS on port 443, check the shared secret in every message, and reject anything else. TradingView can also send a client certificate that your server can verify.
Block duplicates
The same alert can arrive more than once, and a strategy can re-fire on the same bar. Build a signal key from symbol, action and bar time, store it under a unique constraint, and ignore any repeat. On the Pine side, firing once per bar close cuts noise at the source.
Log everything
Record every message received, every duplicate ignored and every action taken. When someone asks "why is RELIANCE on the sheet?", the log answers it.
3. Use case A: signals into a shared Excel file
Many desks want signals in a spreadsheet, not a broker: a research team watching a Nifty 500 strategy, or advisors who act on signals by hand. The common request is a shared Excel file that updates by itself while everyone keeps it open.
Why a file on a shared drive fails
Excel locks a workbook while someone has it open, so a background service cannot write to it reliably. VBA macros that poll for data only run while one particular person has the file open. Neither survives a busy trading day.
What works: Microsoft 365 plus the Graph API
Keep the workbook in OneDrive for Business or SharePoint and update it through Microsoft Graph. Excel's co-authoring then shows new rows to everyone who has the file open, in Excel desktop or in the browser, with no reopening.
Three design rules keep it clean:
The service owns the data, not the sheet. Hold signals in the service's own database and treat the sheet as a view of it. Rules keep running when nobody has the file open.
Protect the signals sheet. People read it; only the service writes to it. Add a separate notes sheet if your team wants to annotate.
Show health. A small Status sheet with the last alert received and service status tells people the difference between "no new signals" and "service down".
Lifecycle rules people usually want
Event | What happens on the sheet |
BUY or SELL arrives | New row at the top, newest first; replaces any active row for that stock |
Same alert arrives again | Ignored |
EXIT arrives | Row marked Exited, with a "remove after" time, e.g. end of the next trading day |
After market close | Rows past their remove-after time are deleted |
BUY or SELL with no EXIT | Kept until replaced, or until an expiry you choose |
Stock leaves the index | Flagged, using a daily refresh of the official constituent list |
Use the exchange's trading calendar for anything measured in trading days, so weekends and market holidays are skipped.
The Google Sheets alternative
If your team works in Google Workspace, the same pattern works with the Sheets API. For a single user, a lighter route is a webhook built with Google Apps Script that appends each alert to a sheet. It is quick to set up, but duplicate blocking, expiry rules and health checks are then yours to add.
4. Use case B: executing on Interactive Brokers
To trade on IBKR from a TradingView signal, the receiver hands each signal to an execution service that talks to IBKR through the TWS API. The pieces below are what we built for an options trader whose signals ran on 4-hour bars.
TWS or IB Gateway
Both expose the same API. IB Gateway is lighter and suited to an unattended server; TWS is useful when someone also wants to watch the screen. Either way, the session needs periodic re-authentication, so the service needs automatic re-login and an alert when that fails.
Run exactly one instance. Two copies of the execution service connected at once will both act on the same signal. Enforce a single-instance guard at start-up.
Picking the option contract
An options signal on the underlying still needs a contract. Encode the rules explicitly, for example "nearest monthly expiry at least N days out, strike nearest the money, calls on BUY". Validate every field (symbol, expiry, strike, right, multiplier, exchange) before submitting. One wrong field and the order bounces; worse, the wrong contract fills.
Spread-aware limit orders
Market orders on options can fill far from fair value when spreads are wide. A common pattern:
Read the bid and ask.
Place a limit at or near the midpoint.
If unfilled after a short wait, step the price toward the ask in small increments, rounded to the contract's tick size.
Stop at a maximum price you set, and alert rather than chase further.
Exits that run without you
Once the entry fills, calculate the average fill price and place the exit immediately, for example a limit at entry plus a fixed profit per contract, plus commission. Send a notification (Telegram works well) so the trader can override the exit if they want to hold. If nobody responds, the exit still stands.
Reconcile with the broker
On every restart, and on a timer, compare the service's view of orders and positions with IBKR's. If they disagree, stop and alert. Never retry an order whose result is unknown until reconciliation says it did not happen.
5. One signal, many accounts
Traders who manage several accounts, such as family accounts or a small group of followers, want one signal to trade in all of them.
Use IBKR's advisor structure. A master account can place one order and allocate it across linked accounts using allocation groups or profiles.
Choose the split rule up front: equal quantity per account, or proportional to account value.
Handle odd quantities: decide who gets the remainder when contracts do not divide evenly.
Use one exit price for all accounts, based on the average fill across accounts.
Check fills per account: confirm every account received its share within an acceptable price range.
Copy-trading for other people can raise regulatory questions depending on where you and they are. Get advice before automating trades in accounts that are not yours.
6. Prove the signal before going live
If the signal is computed outside the charting platform (for example, rebuilt from raw price data so it can run on a server), it must match the chart exactly. Off by one candle, and every trade lands at the wrong time.
What usually causes a mismatch:
Bar construction. A 4-hour bar that starts at 9:30 on one feed and 10:00 on another gives different highs and lows, so a different signal.
Session settings. Extended hours on or off changes every bar.
Indicator parameters. Many indicators compound over history, so a small difference in starting values grows over a long lookback.
How to validate:
Match the chart's session template and extended-hours setting in your data feed.
Let the trader enter their own indicator settings in a config file, so proprietary values never need to be shared.
Compare signals candle by candle against the chart over a long window (we use about 60 trading days) and on more than one symbol.
Treat sign-off as a milestone: no order code is connected until both sides agree the signals match.
On our options automation project, this validation step was its own paid phase. It cost a week up front and saved weeks of debugging live trades later.
7. Relay service or custom build?
Hosted relay services such as TradersPost route TradingView alerts to an IBKR account and are the fastest way to start. A custom build makes sense when your rules go beyond what a relay supports.
Need | Relay service | Custom build |
Simple stock or futures entries and exits | Good fit | More than you need |
Custom option contract selection | Limited | Full control |
Spread-aware limit pricing | Varies | Built to your rules |
Exits computed from your average fill | Limited | Yes |
Allocation across your own accounts | Varies by service | Yes, using IBKR's advisor structure |
Signals into a shared Excel file | Not offered | Yes |
Reconciliation and audit trail you control | Partial | Yes |
Cost model | Monthly fee | One-time build plus optional support |
Who owns the code | The vendor | You |
8. Safety checklist
Before any live order:
Paper trade first, for at least a few weeks of real signals
One signal produces exactly one order, even if the alert arrives several times
A timeout is treated as unknown and reconciled, never blindly retried
A global kill switch stops all orders within seconds, from your phone
On restart, the service reconciles with the broker before doing anything
Only one instance of the service can run
Every signal, order, fill and override is logged
Credentials never appear in logs
For a deeper look at reconciliation, kill switches and audit trails, see our guide on AmiBroker to broker execution in India.
Conclusion
TradingView does the analysis; everything after the alert is plumbing. Get the plumbing right with a fast, verified, duplicate-proof receiver, and the same foundation can feed a live Excel sheet for your team or place options orders across several IBKR accounts. Prove the signal first, paper trade second, and keep a kill switch within reach.
Want help deciding between a relay service and a custom build for your setup?
FAQs
Can TradingView send alerts to Excel automatically?
Not directly. A webhook alert can send each signal to a small service, which then updates an Excel workbook stored in OneDrive or SharePoint through Microsoft's API. Everyone with the file open sees new rows as they arrive.
Do I need a paid TradingView plan for webhooks?
Yes. Webhook alerts need a paid plan and two-factor authentication on your TradingView account. Check how many active alerts your plan allows if you watch many symbols.
Can TradingView place trades on Interactive Brokers automatically?
Not through TradingView's built-in IBKR panel, which is for manual trading. Automation needs a webhook receiver that places orders through the IBKR API, either a hosted relay service or a custom build.
How do I stop duplicate TradingView alerts from creating duplicate orders?
Give every signal a key made from symbol, action and bar time, store it under a unique constraint, and ignore repeats. Firing alerts once per bar close in Pine Script also helps.
Can one TradingView signal trade several IBKR accounts?
Yes. With IBKR's advisor account structure, one order can be allocated across linked accounts by equal or proportional rules. Exits can then be set from the average fill.
Is it better to use Excel or Google Sheets for live signals?
Use whichever your team already works in. Excel needs the file in OneDrive or SharePoint for live updates while it is open. Google Sheets works through its API or Apps Script.


