Every trading bridge restarts eventually. A Windows update reboots the server, a process crashes, a hosting provider does maintenance, or you restart it yourself after a change. The question that matters is not whether it comes back but what happened to the work that was in flight while it was down, and whether the pieces that came back are actually in the state you expect.
This article walks through what a restart interrupts at each of the four layers between a TradingView alert and your broker, what each layer looks like afterwards, and how to check. It applies to any setup: a bridge you built yourself, an open-source project on a VPS, a self-hosted PineConnector terminal, or a hosted MT5 instance on PineConnector Edge. Where a specific product's behaviour is documented, it is cited. Where it is not, this article says so rather than guessing, and that includes PineConnector's own connector.
Layer 1: the webhook that arrives while you are down
When TradingView fires an alert with a webhook, it sends an HTTP request to your URL. If your receiver is restarting, that request either times out or gets an error. TradingView's own rule is strict: "If a remote server takes longer than three seconds to process a request, the request will be cancelled."[1] TradingView also states plainly that "webhooks may occasionally fail to reach the specified URL."[1]
What happens next depends on the error your receiver returned, if it returned anything at all. TradingView documents a resubmission rule: "If the receiving application returns an HTTP response status code between 500 and 599 (except for status code 504)", it resends after 5 seconds, and "The maximum number of webhook sends for one trigger can be 4".[2] So a restart that lasts a few seconds might see the same alert delivered two, three or four times as the receiver comes back up. A restart where nothing answers at all, or where the response is a 504, gets no resend. The alert is gone.
The engineering inference, and it is an inference rather than something TradingView states, is that a receiver which processes an instruction and then returns a 5xx error can be handed the same instruction again and place the order twice, unless it recognises the repeat. Whether any given connector does that is something to verify, not assume.
Layer 2: the connector's own queue
Between receiving a webhook and handing an instruction to the terminal, most bridges hold work somewhere: a queue, a buffer, a database row, or nothing more than a variable in memory. A restart treats these very differently. Work held only in memory disappears with the process. Work persisted to disk or a database survives and may be replayed when the process returns.
Replay sounds like the safer behaviour, and often it is. But an instruction that was written to a queue at 03:14 and replayed at 03:19 is now a five-minute-old market order. Whether you want that executed is a strategy decision, not an infrastructure one. A well-designed bridge either discards stale work after a defined window or makes the window configurable. A bridge you built quickly may do neither.
For PineConnector specifically, the public documentation does not describe what happens to an instruction that arrives while the EA or a hosted instance is restarting, or whether repeated deliveries are recognised. Ask support before relying on either behaviour. The same question belongs on the list for any provider.
Layer 3: the MT5 terminal and the Expert Advisor
An Expert Advisor only runs inside a running terminal. MetaQuotes lists the ways an EA stops, and the first is simply to "Turn off the trading platform".[3] A reboot turns off the platform. That much is obvious. The less obvious part is what has to be true for the EA to be running again afterwards.
On a Windows VPS, three things have to happen in order. Windows has to finish restarting, which it does on its own schedule: Microsoft's guidance is that after installing an update Windows "attempts to automatically restart outside of active hours", and that "Devices that don't have locally signed-in users, or active RDP sessions, are restarted."[4] Then the terminal has to launch. A VPS provider's troubleshooting guide is blunt about this: "MetaTrader does not restart after a VPS reboot automatically unless you configure it to", with the fix being a shortcut in the Windows Startup folder.[5] Then the EA has to be attached to a chart with Algo Trading enabled and the broker connection re-established.
A terminal window that is open is not proof of any of the last two. The check is: is the EA on the chart, is Algo Trading on, and does the terminal show a live connection to the broker.
Layer 4: the broker's server, which does not restart
This is the layer that a restart does not touch, and it changes how you should think about the risk. Your open positions and your pending orders do not live in your terminal. MetaQuotes describes Stop Loss and Take Profit orders as "stored and executed on the broker's server" and states they "do not depend on the performance of the trading platform".[6] The same page notes the flip side: "the Expert Advisor cannot manage its positions in case of a computer failure or server connection loss".[6] One exception worth knowing: MetaQuotes states that "The Trailing Stop is executed in the trading platform rather than on the server (like Stop Loss or Take Profit)",[7] so a trailing stop managed by the terminal stops trailing while the terminal is down.
The practical consequence: a restart cannot lose an open position or a server-side stop. What it can do is prevent new instructions from being executed, prevent the EA from managing anything it manages from the terminal side, and, at layer 1 and 2, cause instructions to be duplicated or dropped.
A restarted process does not prove correct recovery
The mistake that causes real losses is treating "the process is running again" as "everything is fine". After any restart, planned or not, there are four reconciliation checks that take a few minutes and answer the questions the green status light cannot.
| Check | Where to look | What a problem looks like |
|---|---|---|
| Open positions match what your strategy expects | MT5 Trade tab, or your broker's web portal | A position you did not expect, or one that should exist and does not |
| Orders placed during the gap | MT5 History tab for the restart window; your connector's signal log | Fills you cannot match to an alert, or alerts with no fill |
| Duplicated instructions | Connector log entries with the same alert content and timestamps seconds apart | Two entries for one TradingView trigger; two positions of the same size |
| Terminal state | The terminal itself | EA not on the chart, Algo Trading off, "No connection" in the status bar |
For PineConnector users, the connector's signal log is the portal's Signals Log, which the documentation describes as showing "timestamps indicating when our server received the signal and when the PineConnector EA processed it".[8] A signal with a received timestamp inside the gap and no processed timestamp is the thing to investigate.
A safe restart drill, on a demo account
You do not have to wait for Windows to test this. On a demo account, with a demo-only TradingView alert:
- Note the current open positions and pending orders at the broker.
- Restart the bridge deliberately: reboot the VPS, kill the process, or, on PineConnector Edge, use the portal's restart control (see the next section).
- While it is down, fire one demo alert. Note the exact time.
- When everything reports as running, run the four checks in the table above.
- Record what happened to the alert sent during the gap: executed late, dropped, or executed more than once.
Whatever you observe is the actual recovery behaviour of your setup. It may be perfectly acceptable. The point is that you now know it instead of assuming it.
What is documented for PineConnector Edge, and what is not
PineConnector Edge is managed MT5 hosting included in every PineConnector plan,[10] currently in early access.[9] On the restart question, its guide documents the following.
- Supported: a manual restart control. The guide says to "Click Settings to access the controls for manually restarting or terminating your Edge MT5 instance."[9] This is what you use for the drill above.
- Not available yet: terminal logs. "Trading account data, including account balance, and the Experts and Journal logs are not yet available on the Edge page."[9] So on Edge, the post-restart terminal check relies on the portal's connection status and the Signals Log rather than reading the Experts tab yourself.
- Not editable yet: EA settings. "EA settings currently use a fixed default configuration and cannot be edited."[9]
- Recommended: "We recommend using a demo account for your first setup and test trade."[9] The restart drill belongs in that same demo phase.
Not documented: whether a stopped hosted terminal is restarted automatically and how quickly, what happens to an instruction that arrives during a restart, and any uptime commitment. None of these appear in the guide as of this article's review date. Ask PineConnector support for their current answers before you depend on them, and treat the absence of documentation as an open question, not as a yes or a no.
What managed hosting does change is who performs layers 3 and 4 of the recovery. Windows patching, relaunching the terminal and re-attaching the EA are PineConnector's job on Edge. Layers 1 and 2 (whether your alert was delivered, duplicated or dropped) and the reconciliation checks remain yours on any setup, hosted or not.
Who should read this differently
If you run third-party Expert Advisors or trade on MetaTrader 4, Edge is not an option, since it runs only PineConnector's connector[9] and is MT5 only.[10] Your restart story is the VPS one: Active Hours, a Startup-folder shortcut and your own monitoring. The seven problems with a VPS for MT5 covers that in detail, and PineConnector Edge vs running your own VPS lays out who is responsible for what under each model.
If you built your own bridge, the restart drill here is one of nine tests in the tests to run before going live, which also covers repeat delivery, broker rejection and lost responses.
Frequently asked questions
Can a restart close my open positions?
Not by itself. Positions and server-side Stop Loss and Take Profit orders are held at the broker, which MetaQuotes says "do not depend on the performance of the trading platform".[6] A trailing stop managed from the terminal is the exception: it stops trailing while the terminal is down.[7]
Will TradingView resend an alert my bridge missed?
Only if your receiver answered with a 5xx status other than 504, and at most three more times, five seconds apart.[2] If nothing answered, or the request exceeded three seconds, there is no resend.[1]
Does PineConnector Edge restart my terminal automatically?
The Edge Guide documents a manual restart control and does not describe automatic restart behaviour or an uptime commitment.[9] Ask support for the current answer.
How often should I run the restart drill?
Once when you set up, and again after any change to the bridge, the terminal, the EA version or the hosting. A drill on a demo account costs a few minutes; discovering the behaviour on a live account costs more.
Next step: if you have not yet done so, work through the TradingView-to-MT5 setup guide on a demo account and finish with the restart drill above.
Reviewed 10 September 2026. Facts and prices were checked against the linked sources on that date.
Sources
- TradingView – How to configure webhook alerts, accessed 10 September 2026.
- TradingView – Webhook resubmission, accessed 10 September 2026.
- MetaQuotes – MetaTrader 5 Help: Algorithmic Trading (Expert Advisors), accessed 10 September 2026.
- Microsoft Learn – Manage device restarts after updates, accessed 10 September 2026.
- TradingFX VPS – VPS Troubleshooting: Common Trading Issues & Fixes, accessed 10 September 2026.
- MetaQuotes – MetaTrader 5 Help: Performing Deals (Stop Loss and Take Profit stored on the broker's server), accessed 10 September 2026.
- MetaQuotes – MetaTrader 5 Help: General Principles (Trailing Stop executed in the platform), accessed 10 September 2026.
- PineConnector Docs – Test Alert (Signals Log timestamps), accessed 10 September 2026.
- PineConnector Docs – Edge (Early Access) Guide, accessed 10 September 2026.
- PineConnector – PineConnector Edge: Hosted MT5 Included in Every Plan, accessed 10 September 2026.
PineConnector executes the instructions you send it. It does not select trades, manage money, or hold funds. Trading carries risk, and past performance of any strategy does not indicate future results.
