One Alert, Six Accounts: The Full Signal Path

We already published the version of this article that runs backwards. TradingView Alert Not Working? Find the Point Where the Signal Died walks the chain from the symptom back to the break, because that is what you need at the moment something is wrong.

This is the same chain in the other direction, when nothing is wrong. It is the article we wanted to read before we built any of it, and the honest version of it contains numbers that are less flattering than the marketing version.

Everything below is how the system actually behaves, not how it is advertised.

The chain, in seven segments

| # | Segment | Who owns it | Bounded by |
|---|---|---|---|
| 1 | Bar closes, alert condition evaluates | TradingView | Your alert's trigger setting |
| 2 | TradingView sends the webhook | TradingView | Their send infrastructure |
| 3 | Endpoint validates and returns 200 | NexumTrader | Kept deliberately short |
| 4 | Fan-out: one signal becomes one row per account | NexumTrader | Runs after the 200 |
| 5 | An EA claims the row on its next poll | Your MT5 terminal | A one second poll interval |
| 6 | Lot size is computed, the order is sent | Your MT5 terminal and broker | Broker execution |
| 7 | Result is reported back to the queue | Your MT5 terminal | 5s and 30s timeouts |

Segments 1, 2 and 6 belong to TradingView and your broker. Segments 3, 4, 5 and 7 are ours. That split matters, because most of the wall clock time in a normal execution sits in segments belonging to somebody else, and the largest single term that is ours is a design decision rather than a performance problem.

A note on the six accounts in the title: the Essential plan covers up to four MT5 accounts, so a six account fan-out is a Pro plan example. The mechanics are identical at any count.

Segment 1: the bar closes

Nothing leaves TradingView until your alert condition evaluates true and the alert fires. Which moment that is depends entirely on how the alert was created, and this is the first place people lose time without noticing.

An alert set to "Once Per Bar" fires the moment the condition becomes true inside a forming bar. An alert set to "Once Per Bar Close" waits for the bar to complete. On a 15 minute chart that is a difference of up to fifteen minutes, which dwarfs everything else in this article combined.

It is also where repainting lives. A condition that is true mid bar and false at close will have already sent you an order. That is a property of the alert, not of the bridge, and no routing layer can undo it.

The payload grammar we accept is in our webhook payload reference.

Segment 2: the webhook leaves TradingView

TradingView POSTs your alert message to the URL on the alert. One request, fire and forget.

The important property, and the one that shapes everything downstream: by TradingView's own documentation, a failed webhook delivery is not retried. If the request fails, times out, or lands on an endpoint that answers slowly enough to trip their timeout, that signal is gone. There is no second attempt and no queue on their side.

That single fact is the reason segment 3 is built the way it is.

Segment 3: the endpoint answers fast, on purpose

Our webhook endpoint does the smallest possible amount of work before it replies:

1. Parse the body
2. Validate its shape
3. Look up the dashboard_id and confirm the configuration exists and is active
4. Return 200 {"success":true,"message":"Signal received"}

Everything else, and we mean everything, happens after that response has already gone back to TradingView.

This is worth being explicit about, because it is easy to present dishonestly. The response time TradingView sees is not the routing time. It is the validation time. If we quoted the 200 as our latency figure it would be a small and very impressive number that described almost nothing. The work that actually gets an order onto your accounts starts after that response and is measured separately below.

The reason for the split is segment 2. Since TradingView never retries, an endpoint that does its real work before answering is an endpoint that loses signals whenever the real work is slow. Answering first and working second trades a nice number for a signal that does not vanish.

Not every request gets a 200. A missing or unknown dashboard_id gets a 403, a malformed payload gets a 400, and a retired dashboard gets a 403 rather than a silent success.

Authentication, stated plainly. Two paths exist. A JSON payload requires an HMAC signature header and fails closed without one. The comma separated payload our documentation teaches, and the one nearly everyone uses, carries no signature and is authenticated by the dashboard_id inside the message itself.

Two qualifications on that, because the short version flatters us. The generated dashboard_id is 128 bits of cryptographic randomness, but the field accepts a custom value and only enforces a maximum length, so a short one you chose yourself is exactly as guessable as it looks. And the signing secret behind the JSON path is one shared server side secret, not a per customer key, so a signature proves the payload came from something holding that secret, not that it came from your account.

Either way, treat the alert message the way you would treat a password. Do not paste it into a published Pine script, a screenshot, or a support thread.

Segment 4: one signal becomes six

This is the segment that does not exist in a single account bridge, and it is where our architecture differs from a copier.

There is no master account. Nothing is mirrored. The inbound alert is a single instruction, and the fan-out asks, per account, whether that instruction applies. For an entry, an account is eligible only if all of the following are true:

• It is flagged as connected and its connection status is currently online, which are two separate checks
• Auto trading is enabled on it
• Its symbol list covers the symbol in the payload, where gold and silver aliases are treated as equivalent
• The current time falls inside its trading windows, if any are configured

An account that has never reported a symbol has an empty symbol list, and an empty list matches nothing, so it is excluded rather than included.

Close and modify instructions are deliberately less restricted: a close-all bypasses the symbol filter entirely, and trading windows are not applied to them at all. A window that stops you opening a position should not also trap you inside one.

Every account that passes gets its own row in the trade queue, tagged with a shared signal_group_id so the dashboard can display the whole fan-out as one event. Six eligible accounts means six independent rows, six independent lot sizes, and six independent outcomes. One can fail while five fill.

The eligibility conditions are documented in how signal flow works, and the queue's own status and reason columns are in the signal log reference.

The honest edge case. The two kinds of exclusion do not look the same in the log. An account blocked by a trading window gets a row of its own, marked skipped, with a reason you can read. An account that is offline, has auto trading off, or does not carry the symbol is filtered out by the eligibility query, so no row is written naming it. The one exception is when nothing at all is eligible, in which case a single collective row is recorded so the signal does not vanish silently.

The practical consequence: if you run six accounts and five rows appear, the missing one is the one to check first, and its absence is the message.

Segment 5: an EA claims the row

Here is the largest single term in the budget that belongs to us.

Each EA polls once per second. On each poll it claims one pending row for its account, oldest first, using a row level lock that skips anything another instance already holds. The claim flips the row from pending to processing.

A one second poll interval means the wait between a row being written and a row being claimed is normally distributed between zero and one thousand milliseconds. The average is five hundred. Nothing in the current design gets below that.

The upper end is not as tidy. In the normal case the wait is under a second, but a poll can be missed, a terminal can be busy, and a connection can drop, which is precisely why the timeouts in segment 7 are measured in seconds rather than milliseconds.

We are stating the poll interval because it is the number that gets omitted. Every bridge in this category advertises speed, and we have not found one that publishes its poll interval. Ours is one second, it is a compile time constant rather than a user setting, and for the strategies this product is built for, which are alert driven and typically operate on one minute bars and slower, it is not the binding constraint. If you are running something where five hundred milliseconds of expected queueing changes the outcome, this is the paragraph that should tell you so before you subscribe rather than after.

The poll also carries your account's balance, equity and margin back to us, and doubles as the heartbeat.

On the heartbeat, one caveat that belongs in an honest article. An account is marked offline after ten seconds without a poll, but nothing sweeps for stale accounts on a timer. The check runs when a dashboard is open in your browser, and stale trades are expired when some EA next polls. If every terminal stops at once and no dashboard is open, the state you see is the last state somebody observed, not a live one.

Segment 6: sizing happens on your machine, then the order goes

Lot size is calculated in the EA, on your own terminal, at the moment of execution. The server sends inputs, not a lot size. This is deliberate: the balance used in the calculation is the balance the terminal itself reported on that same poll, so sizing is never based on a stale figure the server happened to be holding.

The calculation, described rather than recommended:

1. Risk amount is derived from the account balance and the account's configured risk percentage, with a per signal override applied if the alert carried one
2. The loss on one lot at the given stop distance is obtained from the platform's own profit calculation function for that symbol, with a tick value fallback if the platform declines to answer
3. Lot size is risk amount divided by that per lot loss
4. The result is rounded to the symbol's volume step and clamped to its minimum and maximum
5. If the platform reports an initial margin requirement and the required margin would exceed eighty percent of free margin, the size is reduced to fit and rounded down

Two details in that list are easy to miss and both can surprise you.

A per signal risk override is not unlimited. The EA carries its own maximum risk input, five percent by default, and an override above it is clipped to it without failing the trade. The number in your alert is a request, not a guarantee.

The margin step is conditional. Many brokers report no initial margin figure for FX, deriving margin from contract size and leverage instead, and where that figure is absent the eighty percent check is skipped entirely rather than approximated.

The full worked version is in the lot sizing reference. This is a description of how the software computes a number from settings you chose. It is not a recommendation about what those settings should be.

Why the same alert produces different lot sizes on different accounts. Because balances differ. That is the entire point of the architecture, and it is also the arithmetic that makes fixed lot copying dangerous across unequal accounts, which we worked through in One Strategy, Multiple Prop Firm Accounts.

Filling mode is negotiated per symbol. The EA reads the symbol's supported filling modes and picks Fill or Kill if available, otherwise Immediate or Cancel, otherwise Return. If the broker rejects the order with the unsupported filling mode code anyway, the EA retries with Fill or Kill and then with Return. That is a fixed fallback pair rather than a sweep of everything the symbol claims to support, and it applies to opening a position, not to closing or modifying one.

Slippage tolerance is fixed. Fifty points on entry, thirty on close. In points, not pips, so on a five digit currency pair fifty points is five pips. There is no setting for it.

A normal entry is usually two requests, not one. After the position opens, the EA reads it back and compares the stop and target actually sitting on the position against the levels recalculated from the real fill price. If they differ by more than half a point it issues a modification to correct them. When your alert specified stop and target as absolute prices there is nothing to recalculate, so the second request only fires if the broker failed to apply them. When you specified them in pips, this is what re-anchors them to the fill instead of the pre-order quote. The correction is fire and forget: if it fails it is logged, and the trade is still reported as done.

Segment 7: the result comes back

The EA reports the outcome, and the row moves to done or failed. A failure carries the broker's return code and comment, translated into readable text for the common cases such as a stop that violates the broker's minimum distance, a closed market, or a price that moved.

Three bounds are worth knowing because they define the outer edge of the whole chain:

| Condition | Bound | Result |
|---|---|---|
| Row sits at pending, unclaimed | 5 seconds from creation | Marked failed, "not picked up within 5 seconds" |
| Row sits at processing, claimed but unfinished | 30 seconds from the claim | Marked failed, "claimed but not completed" |
| Account stops polling | 10 seconds | Marked offline |

The thirty second clock starts when the row is claimed, not when it was created, so a row that is picked up late can legitimately live for around thirty five seconds before it is written off.

The five second bound is the one that matters most. If no EA claims a row within five seconds, the signal is dead rather than late. That is a deliberate choice: an order placed eight seconds after its alert is often worse than no order at all, and we would rather show you a failure you can see than a fill you did not expect.

Where the time actually goes

This table is not filled in yet, and we are not going to guess.

| Segment | Owner | Typical | Notes |
|---|---|---|---|
| Alert fires to webhook sent | TradingView | [MEASURE] | Not observable from our side |
| Webhook sent to 200 returned | NexumTrader | [MEASURE] | Validation only, not routing |
| 200 returned to row written | NexumTrader | [MEASURE] | Runs after the response |
| Row written to row claimed | Your terminal | 0 to 1000ms, mean 500ms | Known from the one second poll interval |
| Claim to order sent | Your terminal | [MEASURE] | Includes lot size calculation |
| Order sent to fill confirmed | Your broker | [MEASURE] | Broker and account type dependent |
| Fill to result recorded | Your terminal | [MEASURE] | Reported on the same connection |

Only one row in that table can be stated today, and it is stated from the design rather than from a measurement. The rest requires instrumentation that does not exist yet, run across a range of brokers, on a hosted terminal and a local one, and reported as a distribution rather than a single number. When we have that, this table gets filled in and this paragraph gets deleted.

Until then, we would rather publish an empty column than a comfortable number. A latency figure that nobody measured is a marketing claim wearing an engineering costume, and this category has enough of those.

Frequently asked questions

Does the alert reach my broker in under a second? We do not have a measured answer and will not publish an estimate as if we did. What can be stated from the design: the queue wait alone is normally between zero and one thousand milliseconds because the EA polls once per second, and TradingView's send time and your broker's execution time are outside our system entirely.

Why does the dashboard show six rows for one alert? Because six accounts were eligible. Each row is an independent order with its own lot size and its own outcome. The rows share a group id so they display as one event.

Five rows appeared and I have six accounts. What happened? The sixth was not eligible at the moment the signal arrived. Accounts blocked by a trading window appear as a skipped row with a reason. Accounts that are offline, have auto trading disabled, or do not carry that symbol are filtered out earlier and produce no row of their own, so a missing row usually means one of those.

Why did one account fill and another fail? Because they are separate orders to separate brokers. The most common causes are a stop closer than the broker's minimum distance, insufficient free margin, or a market that is closed for that instrument on that server.

Can I make the EA poll faster than once per second? No. It is a compile time constant rather than a user setting.

Does the symbol name get translated for me? No. The symbol in your alert is normalised to upper case when we receive it and then passed through unchanged. If your broker lists the instrument as EURUSD.pro and your alert says EURUSD, the mismatch does not surface as a broker error. The EA polls for work using the symbol on its own chart, so a row written for EURUSD is never claimed by a terminal charting EURUSD.pro, and the signal times out unclaimed instead. Send the name your broker uses, not the name TradingView uses. Gold and silver aliases are the one exception, and they only affect which account is considered eligible, not the name sent to the broker. This is covered in the error code reference.

What happens if the same alert fires twice? Identical signals landing in the same thirty second window are deduplicated per account, so a double fire generally produces one order rather than two. The window is a fixed bucket rather than a rolling one, so two identical signals a second apart can still both execute if they fall either side of a boundary. It is a safety net, not a guarantee, and an alert configured to fire repeatedly will still produce repeated orders by design.

NexumTrader is order routing software. It does not provide trading signals, portfolio management or investment recommendations, and nothing in this article is financial, investment or trading advice. Any figures shown are illustrative. Trading carries a substantial risk of loss.