A duplicate order is two positions where you intended one. The fix depends entirely on where the second one came from, and there are three different places it can come from: the alert fired twice, the delivery was retried, or one instruction was routed to more than one destination. They leave different evidence and need different fixes. Treating them as one problem is how traders end up "fixing" the wrong layer and seeing the duplicate again next week.
This article separates the three mechanisms, shows what each looks like in the logs you already have, gives a safe way to reproduce each on a demo account, and states plainly which parts any connector, PineConnector included, should be asked about rather than assumed. It is written for anyone routing TradingView alerts into a MetaTrader 5 terminal, whether the terminal runs on your own machine, a VPS, or a managed service such as PineConnector Edge.
First, rule out the intended kind
Some "duplicates" are the system doing what it was told. If two accounts are connected to one licence, one alert is supposed to open the same trade on both. PineConnector's FAQ describes this directly: "The multi-instance alerts or signals feature is when you have multiple trading accounts connected to a single trading License ID, and sending an alert to that License ID will replicate the trade instructions to all the connected trading accounts."[1] Two orders on two accounts from one alert is not a fault. Two orders on the same account from one alert is what the rest of this article is about.
Mechanism 1: the alert fired more than once
What happens. The condition in your script became true more than once, and each time produced a separate alert. Nothing downstream did anything wrong; it received two genuine instructions.
Why it happens. Three common causes. First, the same alert exists on more than one chart or timeframe, so one market move satisfies both. Second, the alert frequency allows repeated triggers. TradingView defines the options: "Once per bar" means "the system checks every bar and triggers an alert whenever conditions are met (no more than once per bar)", while "Once per bar close" is the "same as above, but the bar needs to close for an alert to be triggered", and "Once per minute or every time" means "the system checks conditions every minute and triggers an alert whenever conditions are met".[2] A condition that flickers true and false inside one bar can fire repeatedly under the more permissive settings. Third, a script whose logic is evaluated on the open bar can change its mind before the bar confirms. TradingView's own guidance is blunt: "An alert that fires on an open bar may not reflect the final state of the condition after the bar's confirmation. Set the alert's frequency to 'Once Per Bar Close' to avoid this issue."[3] For strategy alerts specifically, TradingView notes that "More than one notification can be issued in the same bar" and that "the alert will be stopped if it triggers more than 15 times in 3 minutes".[4]
What the evidence looks like. The TradingView alert log shows two or more entries, each with its own trigger time. The connector's Signals Log shows one receipt per alert. PineConnector's documentation describes the Signals Log entry as having "timestamps indicating when our server received the signal and when the PineConnector EA processed it".[5] Two alert-log entries and two received timestamps that line up with them means the duplication happened upstream.
How to reproduce it safely. On a demo account, create the same alert on two timeframes of one symbol with a condition you can force, such as a price cross near the current price. Watch both the TradingView alert log and the Signals Log. You should see two of everything.
The fix. One alert per intended instruction. Set the frequency to "Once per bar close" unless your strategy genuinely needs intrabar entries, and know that the more permissive settings trade certainty for speed. Remember that editing the script does not change alerts you already created; TradingView saves "a 'snapshot' of the script, its inputs, and the current chart's context" when an alert is created, so old alerts must be deleted and recreated.[3] Hosting cannot fix this layer. A terminal running perfectly on PineConnector Edge will still execute two genuine alerts as two orders.
Mechanism 2: the delivery was retried
What happens. One alert fired, but the webhook notification was sent more than once, because the receiving application answered with an error that TradingView treats as retryable.
Why it happens. TradingView documents the rule: "If the receiving application returns an HTTP response status code between 500 and 599 (except for status code 504) when sending a webhook, the notification will be sent again after 5 seconds." There can be three resends, so a single trigger can produce up to four sends.[6] The dangerous case is a receiver that processes the instruction, then fails while responding, so the order is placed and TradingView still resends. Whether those resends become duplicate orders depends on whether the receiver recognises the repeat. That consequence is our engineering inference from TradingView's documented behaviour, not something TradingView states.
What the evidence looks like. One entry in the TradingView alert log, but several near-identical receipts in the connector's Signals Log within a few seconds of each other, the spacing matching the five-second retry interval. If each receipt was processed and each produced an order, you have a retry duplicate.
How to reproduce it safely. This one needs a receiver you control. Point a demo alert at a test endpoint that deliberately returns a 500 status, and count the deliveries. If you run your own bridge, log every inbound request with its timestamp and body before doing anything else, then compare. If you use a hosted connector, you cannot force its receiver to fail, so the honest test is to ask the provider how repeats are recognised, and to inspect the Signals Log after any incident for clustered receipts.
The fix. For a self-built bridge: acknowledge quickly and process afterwards, and treat the same alert content arriving within a short window as one instruction. TradingView also cancels requests that take too long, so slow processing before responding invites both timeouts and retries.[7] For any third-party connector, including PineConnector: PineConnector's public documentation does not describe how repeated deliveries of the same alert are handled. The FAQ has no entry on duplicate signals or de-duplication.[1] This article therefore makes no claim either way. Ask support how a TradingView resend is treated before you rely on the answer, and check the Signals Log on a demo account after your first week.
Mechanism 3: one instruction, several destinations
What happens. One alert fired, one delivery was received, but the instruction was executed by more than one terminal or on more than one account.
Why it happens. Routing. PineConnector's alert format is "LicenseID,Command,Symbol,Parameters", and the licence ID in the message decides where it goes.[8] Two things multiply that: connecting several accounts to one licence on purpose (the replication feature quoted above) or by accident, and running more than one terminal against the same connection, for example an old VPS terminal you forgot to shut down after moving to a hosted instance. On PineConnector Edge, each hosted instance is tied to a licence at setup: "Select the License ID you would like to use for your Edge connection."[9] If a self-hosted terminal is still attached to that same licence, both can act on the same alert.
What the evidence looks like. One alert-log entry, one received timestamp, but orders on two accounts, or two orders on one account from two terminals, with matching or near-matching execution times in the MT5 history. Check which terminal or account each order came from before you touch the alert.
How to reproduce it safely. On demo, attach two demo accounts to one licence, send one test alert using the documented format, and confirm both accounts trade. Then detach one and repeat. You now know exactly what replication looks like in your logs.
The fix. Audit every place a licence ID is in use: each connected account in the portal, each running terminal, and any old server. When migrating from a VPS to a hosted instance, stop the old terminal before starting the new one, and send a demo alert to confirm exactly one order appears. Edge's portal has "controls for manually restarting or terminating your Edge MT5 instance",[9] and its Bridge page lets you "check how your Edge connection responds to a signal",[9] which is the right place to run that confirmation. Note that on Edge the "Experts and Journal logs are not yet available",[9] so for hosted instances your evidence is the Signals Log plus broker history rather than terminal logs.
Telling them apart in two minutes
| Look at | Repeated alerts | Delivery retries | Multiple destinations |
|---|---|---|---|
| TradingView alert log | Two or more entries | One entry | One entry |
| Connector Signals Log (received timestamps) | One receipt per alert entry | Several receipts seconds apart for one alert | One receipt |
| MT5 history | One order per receipt | One order per processed receipt | Orders on two accounts or from two terminals |
| Fix lives in | Your alerts and script | The receiver's retry handling | Your routing: licences, connections, terminals |
| Can hosting fix it? | No | No; ask the provider how repeats are handled | Partly: one place to see and stop instances |
Where PineConnector fits, and where it does not
Mechanism 1 is entirely yours. Mechanism 3 is largely yours, with the portal as the place to see and control every connection. Mechanism 2 is the one where a connector's behaviour matters most, and it is the one PineConnector's public documentation does not currently describe. That is not an accusation; it is a gap to close with a support question before you depend on the answer. PineConnector Edge, the managed MT5 hosting included in every plan, changes who runs the terminal and gives you one place to start, stop and test each instance. It does not change how many alerts you create, and hosting is not a substitute for knowing how retries are treated.
Frequently asked questions
Is "Once per bar close" always the right alert frequency?
It is the safest default for avoiding repeated intrabar triggers, per TradingView's own guidance.[3] Strategies that genuinely need intrabar entries accept more triggers as the price of speed, and should be tested on demo for exactly this behaviour.
My connector shows two received timestamps five seconds apart. What happened?
That spacing matches TradingView's documented resend interval after a 5xx response.[6] Check the TradingView alert log: if there is one entry, it is a delivery retry, and the question is how your receiver treated the second copy.
Does PineConnector ignore a resent webhook?
Not documented publicly as of the review date. Ask support and test on demo rather than assuming.
I moved to a hosted terminal and now get double orders. Why?
The most common cause is an old terminal still running against the same licence. Stop it, then send one test alert and confirm exactly one order appears.
Next step
Run the demo reproductions above once, so you know what each mechanism looks like in your own logs. For the wider set of pre-live checks, see the nine tests to run before going live. If the problem is the opposite, an alert that arrives and produces no order at all, use the stage-by-stage diagnosis. If you run several accounts on purpose, running MT5 for multiple accounts covers the routing options.
Reviewed 10 September 2026. Facts were checked against the linked sources on that date.
Sources
- PineConnector Docs – FAQ (Multi-Account section), accessed 10 September 2026.
- TradingView – Differences between alert frequencies, accessed 10 September 2026.
- TradingView Pine Script docs – FAQ: Alerts, accessed 10 September 2026.
- TradingView – Strategy alerts, accessed 10 September 2026.
- PineConnector Docs – Test Alert, accessed 10 September 2026.
- TradingView – Webhook resubmission, accessed 10 September 2026.
- TradingView – How to configure webhook alerts, accessed 10 September 2026.
- PineConnector Docs – Syntax, accessed 10 September 2026.
- PineConnector Docs – Edge Guide, 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.
