A Brief Network Fault Should Not Fail Your Trade

Between a Telegram message and your broker, an order crosses several network connections. Any one of them can fail for a fraction of a second, for no reason more interesting than the internet being the internet.

This is what TTMT does so that fraction of a second rarely costs you the trade. It is also about the one thing TTMT will not do, even when doing it would save a trade: send an order a second time without knowing what happened to the first.

The hops between the message and the broker

A signal arrives over a live connection to Telegram. It is read, checked, and sized, which I walked through in what happens in the two seconds after a signal posts. Then the order has to leave.

On the standard cloud connection, it travels from your trading service to the cloud provider and on to your broker. On self-hosted execution, where a terminal runs for your account alone, there are two hops inside TTMT before the broker's own server.

Each hop is a network call. A call needs an open connection, and opening a connection starts with a lookup: turning a name into an address, the same step your browser takes before it loads a site. A failure can land at any of those points, and where it lands decides what is safe to do next.

Connections that are open before the order needs them

The cheapest lookup is the one you never make.

TTMT keeps exactly one live streaming connection per MetaTrader account. Position updates, order fills, and prices all arrive on it, and every part of the system reads from that one feed. TTMT refreshes it, along with its credentials, before either can go stale. You never restart anything.

On self-hosted execution the order path is kept warm as well. Both hops hold their connections open, and a small read-only request goes down them on a schedule to keep them that way. It is never an order. When a signal arrives after a quiet hour, the order normally finds a connection that is already open and skips the setup and the lookup entirely.

What you get from this is unglamorous: the first order of the session is treated the same as the tenth.

A lookup that survives a lost answer

Sometimes a fresh connection is needed anyway, and a lookup has to happen.

The usual behavior of a lookup is to ask once and wait. If the answer gets lost on the way, the wait can run to five seconds before anything gives up. Five seconds is a long time on a signal whose price is already aging.

On the self-hosted order path, TTMT does not wait like that. It asks again quickly, several short attempts inside well under a second, and only then falls back to the ordinary system lookup. A lost answer now costs a fraction of a second.

Two choices in there are deliberate. The lookup does not remember old answers, because a remembered address can point at something that has since moved, and a wrong address is a worse problem than a slow one. And the retries apply to the lookup only. Asking for an address twice is harmless. Sending an order twice is not.

The limit is real and I would sooner state it than have you find it. If the fallback lookup fails too, the order fails, and it is not sent again.

A record of which hop failed

When an order send does fail on the self-hosted path, the record now carries which hop it failed on and the underlying cause.

Nothing in the system acts on that record. It exists for the person investigating afterwards, which is usually me, so that "did this order ever leave?" can be answered from a log line instead of from guesswork. It changes nothing about how your trade is handled.

Why an order with an unknown outcome is never resent

Here is the rule the rest of this article has been working around.

A send that fails can mean three different things. The order never left. The order arrived and filled. The order arrived and the broker refused it. From the sending side, all three can look identical: a connection that went quiet.

The tempting fix is to sort failures into "definitely never sent" and "maybe sent," and resend the first group. I looked hard at that and decided against it. The proof is weaker than it appears. The networking software underneath can, in some cases, repeat a request or follow a redirect on its own, so an error that reads as "the connection never opened" does not prove that nothing reached the other end.

Then weigh the two mistakes. A missed trade costs you the trade. You know what happened, and your account is exactly where it was. A duplicate position is twice the risk you configured, opened without your knowledge, quite possibly while you are asleep. If you size at 1% of your balance, a duplicate is a 2% trade you never agreed to.

A duplicate order is the worst outcome a signal copier can produce. A missed one is second. So TTMT does not resend an order on a connection failure, and that holds even when the evidence suggests the first attempt went nowhere.

What happens instead

Not resending is only half an answer. The other half is finding out what is true.

When a send ends in an uncertain state, TTMT goes to the broker and looks for the order. In the app that state reads as "Couldn't confirm whether the order went through," and it needs no action from you. If the order landed during the glitch, nothing further is sent. That one real order is the trade, and it is managed from there like any other.

If TTMT cannot establish what happened, it does not guess. The order is not sent again, and the trade shows the failure.

Behind that sits the slower, broader check. TTMT periodically compares its own records against the positions your broker holds, which is how it catches anything that changed while a connection was down. Limit orders that fill during a disconnection are picked up when the connection resyncs. If the resync misses one, TTMT queries the broker's order and deal history directly. If both come up short, it raises an alert for manual review on our side.

The same principle runs through how TTMT watches a trade after it's placed: a question that could not be answered is recorded as unanswered, and the broker is the authority on what exists.

What the dashboard tells you when the connection drops

The dashboard tries to be accurate about two different connections: its own link to TTMT, and TTMT's link to your broker. Only the second one affects your trades.

A short interruption on the first is not treated as a failure. The dashboard holds what it last knew for a few seconds before it says anything, so a browser pausing a background tab passes without an alarm. Past that window it tells you it is reconnecting to your account and shows when it last had fresh data. It does not blank the figures.

A problem your broker reports gets no grace period. It is shown immediately.

The System Health indicator in the header covers three levels: the TTMT service, the broker connection, and the broker account itself. Green means all three are healthy, yellow means one is degraded, and red means a critical level has failed. Being connected is not enough to count as healthy. If live prices stop arriving for about 60 seconds, the connection is treated as unhealthy and TTMT starts reconnecting on its own.

If broker health stays red for about five minutes, a banner appears with a Reconnect button. Pressing it re-establishes the link, usually in around 30 seconds. It does not close or modify anything.

Through all of it, the stop loss (SL) and take profit (TP) already placed on your positions live at the broker, and the broker keeps enforcing them. What pauses during a disconnection is live management: new signals, breakeven moves, and take-profit redistribution resume once TTMT has reconnected and resynced.

One state is easy to misread. A closed market is not a disconnection. No prices arrive, so the connection shows as degraded until the market reopens. There is nothing to reconnect, and a signal that arrives while the market is closed is skipped, not queued.

The full reference is in the docs under connection resilience.

Related: what makes an automated signal copier reliable, which covers the questions worth asking any copier about a dropped connection.

Start a free 7-day trial at telegramtometatrader.com, or read how the order gets built in the first place in copying Telegram signals to MT5.