TradingView Alert Fired but Tradovate Did Not Trade: A Practical Troubleshooting Checklist
A simulation-first checklist for diagnosing a TradingView alert that fired but produced no visible Tradovate order. Verify delivery, payload, account, symbol, quantity, and order state.
Your TradingView alert says it fired. You expected a Tradovate order, and the account is empty. Before you resend the alert or change five settings at once, isolate the handoff: did the request arrive, did CrossTrade understand it, did one of your own controls stop it, did it reach the intended Tradovate account, and did Tradovate accept or reject the order?
Each of those leaves a different fingerprint. Work through them in order and you will know which one broke in about two minutes.
TradingView fired the alert. That is not the same as a filled order.
A TradingView alert confirms one thing: TradingView reached its alert condition and attempted its configured webhook action. It does not prove the request arrived, that the payload described a valid order, or that the order reached the account you were watching.
Resending is the wrong first move. If the original request is delayed or already working, the second one doubles your size. Start in a Demo account, change one variable at a time, and let the record tell you where the chain stopped.
1. Find the request in Alert History before you touch anything else
Alert History lists every alert CrossTrade receives, on either broker, with the exact command that arrived. That makes it the fork in the road.
No matching row at all means the request never reached CrossTrade. Stop. The problem is delivery: the webhook URL, the key in it, or the alert's own configuration. Nothing about your payload matters yet.
A matching row means delivery worked, and the row already tells you what happened next. Every alert carries a status of Success, Warning, or Rejected, plus the received timestamp and the execution time. Click the arrow at the left of the row to expand it. You get the execution timeline, the webhook command exactly as CrossTrade received it, and the resulting order details side by side.
Read the command as CrossTrade received it, not as you wrote it in TradingView. Those are frequently different strings, and the difference is usually the whole bug.
Every error and warning also has a help modal in the app that explains that specific failure. Open it before you start changing fields.
2. Read the payload the way CrossTrade read it
A webhook can arrive cleanly and still never become an order. Compare the received command against the current webhook command reference, one field at a time.
For direct Tradovate routing the selector is destination=tradovate;. With no destination field the order routes to NinjaTrader 8, which is the default and which keeps older alerts working unchanged. An alert missing that line is not broken, it is just going somewhere else.
The payload failures that show up most often in Alert History have their own named errors:
TradingView Placeholder Not Replaced. A template variable like {{strategy.order.action}} went out literally because the alert was built against a different script or the placeholder was mistyped. The received command shows the braces.
Missing Required Field. Order types have hard requirements. A limit needs limit_price, a stop needs stop_price, a stop-limit needs both, and tif=gtd needs expire_time.
Unknown Command Type or Unknown Field Name. Sending an unsupported command to Tradovate never fails silently. CrossTrade rejects it with a message naming the command and listing the supported set, and records the rejection.
Some NinjaTrader fields behave differently on Tradovate rather than erroring. strategy_tag is accepted and ignored, because tags live in the add-on's local order book and Tradovate orders never touch it. strategy_id, append_atm, oco_id, stop_loss_stop, stop_loss_limit, and custom_tag are rejected outright, each for a documented reason. If you cloned a working NinjaTrader alert and only swapped the destination line, this is where it bites.
Change one field. Send one test. Record the result.
3. Check whether one of your own controls blocked it
This is the case people miss, because the alert looks fine and the account still does nothing. CrossTrade evaluates your controls before it places anything, and a blocked signal is recorded so you can see it rather than wondering why nothing happened. Trade-window controls apply on both destinations.
Look for Kill Switch Engaged, Closing Only Mode, Outside Trade Window, Maximum Quantity Exceeded, or Market Position Requirement Not Met on the row. Each one is your configuration working as designed:
require_market_positiongates the command on the live position, sorequire_market_position=flatwill refuse to add to an open one.max_positionsblocks an opening order that would add a new instrument once the account is holding that many. Scaling an existing instrument does not consume a slot.- An economic-event lockout or a trading window refuses incoming signals for the duration of the window.
None of these are bugs, and none of them are fixed by resending. Check the control, not the payload.
4. Confirm the Tradovate identity and account
An order can only appear in the account reached by the connected identity. Account Not Connected and Account Not Found are different failures: the first means the link is not live, the second means the name in your alert does not match an account on the linked identity.
Verify the connection on the account-linking page rather than trusting a browser tab that may be signed in somewhere else. Check the environment too. A Demo identity and a Live identity are separate connections, and an alert pointed at one will never show up in the other.
If you recently linked, unlinked, renewed, or switched the selected account, redo the test with the account name written down. Do not infer the target from a display name when several accounts are present.
5. Confirm the contract, not just the symbol
Instrument Format Not Compatible is its own error for a reason. Tradovate accepts three forms, and they are interchangeable: ES1! for the front month, ES 09-26 for an explicit contract, and ESU6 in exchange format. Digit-bearing roots like M2K, 6E, and M6E work in all three forms too.
What is not interchangeable is a root, a continuous symbol, and a dated contract that has rolled. If your alert names an expired contract month, that is a different instrument than the one your account is positioned in.
Write down the exact instrument string, side, quantity, account, and timestamp before you send. The point is not to prove every symbol converts. The point is to remove ambiguity from one test.
6. Working is not filled, and filled is not still open
If the request was accepted and the position panel still reads flat, you are probably looking at the wrong panel. A limit or stop order can be live and working for hours without changing the position. A filled order can leave a position that something else already closed.
Check working and completed orders, not only current positions, and match on account, environment, instrument, and time window together. The order-details section of the expanded Alert History row gives you the CrossTrade side of that comparison.
One Tradovate-specific note: if you set take_profit and stop_loss, both legs are sent GTC and Tradovate activates them on the entry's first fill. Until that entry fills, the bracket is not working yet. An unfilled entry means no visible protective orders, which looks alarming and is correct.
7. Retest with one known-good control
Once you know where the chain stopped, build the smallest test that proves the repair. One Demo account, one instrument, the front month, the smallest quantity the environment allows, and no extra features.
Then add complexity one piece at a time. Multi-account placement and strategy synchronization each add their own decision points, and stacking them onto an unverified single-account path is how a small problem becomes an unreadable one.
Keep a short record as you go: alert time, the exact payload, the Alert History status and error, the target identity and account, the instrument and quantity, the Tradovate order status, and what changed between tests. That record turns "it did not trade" into a reproducible handoff that support can act on immediately.
What this checklist does not claim
This process finds where a workflow stopped. It does not guarantee execution, fills, routing speed, or permission to automate on a particular funded account. Tradovate, TradingView, and any prop firm apply their own account, market, and policy rules, and those remain yours to verify against your current agreement.
The useful outcome is narrower and more practical than a fix-all: once you can separate request, payload, controls, identity, account, and order state, you repair the right layer instead of firing the same alert again and hoping.
For the broader cloud workflow, see How to Trade Tradovate Webhooks Without a VPS. To hand the investigation to an AI client instead of reading rows yourself, see AI trading automation for Tradovate. For a new setup, start with the Tradovate docs and prove the path in Demo before you point it at anything funded.
New to CrossTrade? Start your free 7-day trial and route your first Tradovate alert in Demo. Questions, or want a second pair of eyes on an alert that will not fire? Our team and a few thousand futures traders are in Discord.