TradingView-Tradovate 'Position Closing Timeout'
You click close and get a red 'Position closing timeout' instead of a flat position. Here's what the error actually means, why order and position IDs drift out of sync, and how to force a clean refetch.
When you're managing a live futures position straight off a TradingView chart wired to Tradovate, the exit button is supposed to be instant. One click and you're flat. So it rattles you when you click it and, instead of flattening, a red error slides in: "Position closing timeout." Maybe the trade already closed on Tradovate's side. Maybe it didn't. And for the next several seconds on a fast contract like ES or NQ, you genuinely don't know whether you're still holding size. The same failure shows up in other disguises too: an order fires but the chart still shows the position open, a position ID that no longer matches, a close button that does nothing. Almost all of it traces back to one root cause. TradingView's chart and Tradovate's backend have drifted out of sync on order and position state. Here's what the timeout actually means, what causes the ID mismatch behind it, and how to force a clean refetch so you can get out with confidence.
Quick Checklist for a Position Closing Timeout
- Check Tradovate directly before you react. Open the Positions/Orders panel in the Tradovate web trader. The timeout is a confirmation failure, so your real position there is the source of truth, not the chart.
- Don't spam the exit button. Repeated close clicks can stack duplicate orders once the connection catches up. Click once, then verify.
- Reconnect the broker session in TradingView. Disconnecting and reconnecting the Tradovate account forces the chart to reload the full order and position list from scratch.
- Suspect an ID mismatch. If the chart shows a position or order that Tradovate no longer has (or the reverse), the two sides are referencing different IDs and need a full refetch, not a nudge.
- For integrators and bridges: call
ordersFullUpdateandpositionsFullUpdateto clear cached state and refetch, but only as an edge-case recovery, never on every update. - Keep a manual flatten path ready. Know how to place an opposite market order or use Tradovate's own flatten control if the chart won't close the trade.
What “Position Closing Timeout” Means
Trading directly from a TradingView chart runs on TradingView's Broker API, a two-way contract between the chart and whatever backend is connected (here, Tradovate through the official integration). When you close a position, the library calls the integration's closePosition method and then waits for a confirmation that the position's id now has a quantity of 0. Per TradingView's Broker API documentation, the library waits up to about 10 seconds for that confirmation to come back through the Trading Host. If no matching positionUpdate shows up in that window, the library gives up and throws the error you're staring at: "Failed to close position: Position closing timeout."
Here's the nuance that matters. The timeout describes the confirmation, not necessarily the order. Tradovate may have already flattened the position; TradingView simply never heard back in time. A lagging feed, a dropped session, or a heavy modify/cancel burst can all swallow that confirmation. That's exactly why your first move is always to check the true state on Tradovate rather than click close again. The order side of chart trading uses the same roughly 10-second window, so placing or modifying an order can throw an equivalent timeout.
A related and nastier variant is an outright ID mismatch. TradingView tracks every order and position by an id the integration hands it. If that backend id changes between when the request is submitted and when it's processed, the library ends up pointing at an id that no longer exists. So close and modify requests reference stale data and quietly fail, and the UI shows orders or positions that don't line up with the account. TradingView's documentation calls this out directly and gives a specific recovery path for it.
Top Causes of a TradingView-Tradovate Position Closing Timeout
1. The confirmation never arrived inside the ~10-second window
This is the plain-vanilla case. The close request went out, but the positionUpdate (with the matching id and qty of 0) didn't make it back to the chart within the library's timeout. A congested market-data feed, a brief network hiccup, or a Tradovate-side slowdown is enough to miss the window even when the position closes just fine.
2. An order or position ID changed after submission (the mismatch)
If the backend re-issues an id between submission and processing, the chart is now referencing something that no longer exists. Close and modify actions target the old id, so they fail, and the position or order looks "stuck" on the chart while Tradovate shows a different reality. This is the exact "dynamic ID change" edge case the Broker API docs describe.
3. A stale or dropped broker session
TradingView caches order and position state for the connected account. If the Tradovate session drifts, drops, or gets bumped (say, by hitting the concurrent-session limit across web, desktop, mobile, and TradingView), the chart can keep showing a snapshot that no longer matches the live account, and a close against that snapshot times out.
4. A Tradovate-side outage, freeze, or rate-limit
During a Tradovate incident, or when heavy modify/trailing activity exhausts request limits, orders can freeze and confirmations stop flowing. You'll see it as exit buttons that don't respond, "order can't be modified" loops, and positions that won't close until the connection is reset. When Tradovate itself isn't confirming, no amount of clicking on the chart will clear the timeout.
How to Fix a Position Closing Timeout: Step-by-Step
Confirm the true position state in Tradovate first
Before you touch the chart again, find out what's actually open. Log into the Tradovate web trader and open the Positions and Orders panels. If the position is already flat there, the timeout was a false alarm, the confirmation just didn't reach TradingView, and there's nothing to close. If it's still open, note the exact quantity and any working orders (stops/targets) so you know precisely what needs to be flattened. Treat Tradovate as the source of truth and the chart as a possibly stale mirror.
Force a fresh state load by reconnecting the broker in TradingView
If the chart and Tradovate disagree, make TradingView throw away its cached snapshot and reload from scratch. In the chart's trading panel (the Account Manager area), open the connected Tradovate account's controls and disconnect, then reconnect the broker session. Reconnecting triggers a first-time-load style fetch, so the full, current list of orders and positions gets pulled fresh, which clears mismatched IDs and stale entries. A page refresh followed by a reconnect does the same thing if you can't find a direct reconnect control.
For integrators: trigger ordersFullUpdate / positionsFullUpdate
If you build on TradingView's Broker API, or run a bridge that speaks it, the docs give you an explicit recovery for ID mismatches. Calling ordersFullUpdate and positionsFullUpdate forces the library to clear its existing data and refetch the full list of orders or positions, exactly as it does on first load. That wipes out any stale id the chart was holding. These full-update methods are edge-case tools only, meant for rare situations like dynamic ID changes, not for your regular update flow. Your default for keeping the chart in sync should stay orderUpdate and positionUpdate, which patch the UI without a full reload.
Flatten manually if the position is genuinely still open
If Tradovate confirms the position is real and reconnecting didn't let you close it from the chart, exit directly in Tradovate. Use the account's flatten control, or place an opposite market order for the exact open quantity (sell to close a long, buy to close a short), then cancel any orphaned stop/target left working. Doing this in the Tradovate web trader instead of fighting the timed-out chart button gives you a clean fill and avoids stacking duplicate closes.
Troubleshooting Table
| Error | Meaning | Fix |
|---|---|---|
| Failed to close position: Position closing timeout | The close confirmation didn't reach the chart within ~10 seconds | Check Tradovate for the true state; if still open, reconnect the broker or flatten directly in Tradovate |
| Position/order shown on chart but missing in Tradovate | Chart is holding a stale id (dynamic ID mismatch) | Reconnect the broker to force a full refetch; integrators call positionsFullUpdate / ordersFullUpdate |
| Order placing / modifying timeout | Order confirmation missed the same ~10-second Trading Host window | Verify the order status in Tradovate before resubmitting; reconnect if the chart is out of sync |
| Order can't be modified / exit button does nothing | Frozen session or exhausted request limits during heavy activity | Stop clicking, flatten via an opposite market order in Tradovate, then reconnect |
| Position won't close during an outage | Tradovate isn't confirming state; feed or platform incident | Manage risk from Tradovate directly or a backup connection; wait for the incident to clear |
Prevent This with PickMyTrade
PickMyTrade routes your TradingView alerts to Tradovate through a dedicated bridge instead of leaning on the chart's live Broker-API session, which removes most of the state-sync failure points behind a closing timeout:
- Reliable close and flatten signals, a single close or flatten alert sends a clean exit to Tradovate, so you're not depending on a chart button whose confirmation timed out.
- Consistent order state, the bridge tracks the order it sent and its status, so your exits don't hinge on the chart's cached IDs staying perfectly in sync.
- Rate-limit-safe routing, spaces out order and modify traffic so you don't exhaust Tradovate's request limits and trigger the freezes that cause timeouts.
- Multi-account sync, mirrors the same validated exit across every connected account at once, instead of leaving one account stuck open.
The payoff is fewer "did that actually close?" moments, and cleaner logs when you do need to debug.
Stop Babysitting Timed-Out Exits
Link your alerts today and trade rejection-free with reliable close and flatten signals that don't depend on a chart's cached state.
Start Your Free 5-Day TrialFrequently Asked Questions
Not necessarily. The timeout means TradingView never got a confirmation back within about 10 seconds. The position may already be flat on Tradovate. Check the Positions panel in the Tradovate web trader before you click close again, so you don't accidentally open a fresh position in the opposite direction.
That's the ID-mismatch symptom. The chart is referencing an order or position id that changed or no longer exists on the backend, so its cached view is stale. Reconnecting the Tradovate broker in TradingView forces a full refetch and realigns both sides.
They tell the TradingView library to clear its existing order or position data and refetch the entire list as if it were loading for the first time, which clears stale IDs. They're integrator-facing methods meant only for rare edge cases like dynamic ID changes, not for routine updates.
No. TradingView's docs are explicit that full updates are heavy and reserved for edge cases. The default for keeping the UI current is orderUpdate and positionUpdate, which patch individual items without clearing and reloading everything.
It's built into TradingView's Broker API. After a close or order action, the library waits up to roughly 10 seconds for a confirmation through the Trading Host; if none arrives, it returns a timeout. The fix is about getting a valid, matching confirmation back in time, or refetching state, not about retrying blindly.
During a timeout the connection can be lagging, so repeated clicks queue multiple closes that all fire once it catches up. Click once, verify in Tradovate, and if it's stuck, flatten there directly instead of hammering the chart button.
Yes. If you're logged in across web, desktop, mobile, and TradingView at once, sessions can get bumped and the chart's state goes stale, which surfaces as timeouts and frozen orders. Sign out of extra sessions and keep a single active device.
Usually neither in isolation. It's a synchronization gap between the two. TradingView is waiting on a confirmation; Tradovate is either slow to send it, changed an ID, or is mid-incident. The reliable fixes (check true state, reconnect to refetch, flatten directly) work regardless of which side lagged.
This guide is for educational and informational purposes only and is not financial, investment, or trading advice. Trading futures and other leveraged products carries a substantial risk of loss and is not suitable for every investor. PickMyTrade is an independent third-party automation platform and is not affiliated with, endorsed by, or sponsored by Tradovate, Inc. or Bookmap. All related names, logos, and trademarks are the property of their respective owners. Platform features and steps change over time, so always confirm the current process in the official platform documentation before acting.