TTMT Docs

Appearance

Connection Resilience ​

Trading automation requires constant, reliable connectivity. TTMT maintains connections to two external systems simultaneously: Telegram (for receiving signals) and your broker (for trade execution). Either connection can drop at any time due to network issues, server maintenance, credential expiration, or broker downtime.

TTMT handles all of this automatically. Connections are monitored, refreshed, and reconnected without manual intervention. State is reconciled after every reconnection. Stale data is detected and flagged. You should never need to manually restart your trading service because of a connection issue.

How You Connect to Your Broker ​

TTMT reaches your MetaTrader account through a provider — the plumbing that carries orders and live prices between TTMT and the broker. Which provider you are on determines a few behaviors, so it is worth knowing yours.

ProviderStatusNotes
MetaAPI CloudDefault / recommendedThe standard path. Broker-managed features (including broker-side trailing) are available where your broker supports them.
Self-Host TerminalLimited previewRuns against a self-hosted terminal. Enabled per account on request.
Self-Host ClientLimited previewA self-hosted client provider. Enabled per account on request.

Limited preview

The self-host providers are in limited preview and are enabled per account on request. Availability, behavior, and naming may change before general release. Contact support if you'd like to take part. Most accounts run on MetaAPI Cloud.

The self-host providers behave the same as Cloud for everyday trading, with one safety-relevant difference: they do not support broker-managed trailing stops. See Position Protection for how trailing degrades on self-host.

One Streaming Connection Per Account ​

TTMT keeps exactly one live streaming connection per MetaTrader account — a single shared feed that carries every position update, order fill, price tick, and deal event. This is deliberate: MetaAPI permits only one streaming connection per account, and a second parallel connection would fight the first, causing rate-limit storms and dropped updates. TTMT never opens a competing connection; every part of the system reads from the one shared feed.

For you, this means the connection either exists and is healthy or it is being re-established — there is no "half-connected" state where two feeds disagree. The dashboard health indicators reflect that single feed's state directly.

Connection States ​

Rather than a fixed schedule of refreshes, think of your connection in terms of the states you can actually see in the dashboard:

TTMT refreshes long-lived connections and their secure credentials on its own before they can go stale — you never manage tokens or restart anything. When a connection is idle (trading paused on that account), it is cleaned up and re-established on demand the next time it is needed. What you see in the dashboard is the current state of the one shared feed, not the machinery behind it.

One connection, always reused

Because there is a single shared streaming connection per account, TTMT reuses it rather than opening new ones. This prevents the conflicting operations, duplicate event handlers, and rate-limit churn that multiple parallel connections to the same account would cause.

Live Connection Manager ​

The live connection manager handles the real-time data feed from your broker -- the stream of position updates, order fills, price changes, and deal events that TTMT relies on for live monitoring.

Defending Against Stale Position Data ​

One of the most subtle connection issues is ghost positions: stale position data that does not reflect reality on the broker. These appear during resynchronization events and can cause TTMT to believe positions exist when they have already been closed.

How ghost positions happen:

  1. The broker connection initiates a resync (periodically or after reconnection).
  2. During resync, the local position data may temporarily contain outdated information.
  3. If TTMT reads this data during the resync window, it sees positions that no longer exist.

TTMT's defense (3-layer sync guards):

GuardWhen It RunsWhat It Does
Periodic check guardEvery position sync cycleValidates positions against broker state before acting on them
Price update guardWhen new price data arrivesChecks position validity when price data arrives
Order completion guardWhen an order completesVerifies position existence after order events

Authoritative Broadcast ​

After each full sync completes, TTMT performs a clean-state refresh: it replaces its in-memory position state entirely with the freshly synced state. This purges any ghost positions left over from the resync transition.

Health Check System ​

TTMT monitors health at three independent levels. A failure at any level triggers appropriate responses, from logging to connection refresh to trading pause.

3-Level Health Assessment ​

LevelWhat It ChecksFailure Impact
ServiceIs the TTMT background service running and responsive?Complete outage -- no signals processed, no trades managed
Broker ConnectionIs the broker connection active and receiving live prices?Cannot execute trades or monitor positions
BrokerIs the MetaTrader account responsive?Cannot place orders; existing positions still monitored

Service Level ​

The service health check verifies that the TTMT background service is alive, accepting requests, and running its monitoring work. This is the most basic health check and catches crashes, out-of-memory conditions, and startup failures.

Broker Connection Level ​

The broker connection health check verifies that:

  • The connection is established
  • Live prices are arriving -- the load-bearing signal; if quotes go stale for about 60 seconds, the connection is treated as unhealthy
  • The last synchronization succeeded
  • The connection age is within limits

Any one of these failing means TTMT treats the connection as unhealthy and won't trust it -- being merely "connected" isn't enough. If the broker connection is degraded, TTMT attempts automatic reconnection before flagging the issue.

Broker Level ​

The broker health check goes one level deeper -- it verifies that the MetaTrader account itself is responsive. The broker connection might be healthy, but the broker's server could be down for maintenance. This check catches that scenario.

TIP

All three health levels are visible in the dashboard header under the System Health indicator. Green means all three are healthy. Yellow means one level is degraded. Red means a critical level has failed.

The Reconnect Button ​

If broker health stays red for about five minutes, the dashboard surfaces a clickable Reconnect button. This is user-in-the-loop: you click it, and TTMT re-establishes the broker connection -- nothing redeploys or restarts on its own. Recovery is usually a matter of seconds. The five-minute prompt threshold is separate from the roughly 60-second live-price staleness window above.

Full step-by-step guidance for the Reconnect button lives on Connection Issues.

Position Sync ​

Even with reliable connections, state can drift between TTMT's internal records and the broker's reality. Positions can be closed manually, by a trailing stop, or by the broker itself (margin call, end-of-day). The position sync system detects and resolves these discrepancies.

How It Works ​

TTMT periodically compares its own records against your broker's actual positions to detect opens, closes, and modifications. Positions that have not been updated recently are flagged for investigation.

What Position Sync Catches ​

DiscrepancyDetectionResolution
Position closed by broker (not by TTMT)Position in TTMT's records but not on brokerMark as closed, reconcile P&L
Position opened manuallyPosition on broker but not in TTMT's recordsIgnore (TTMT only manages its own trades)
Position modified externallySL/TP values differ between TTMT and brokerUpdate TTMT's records to match broker
Stale position dataPosition not updated recentlyFlag for investigation, trigger re-query

Background Safety Check for P&L Recovery ​

When a position closes outside of TTMT's awareness (e.g., the trailing stop fires during a brief disconnection), a background safety check ensures the trade record is properly finalized.

TTMT periodically queries the broker's trade history to find the deal that closed the position, extracts the actual P&L, and updates TTMT's trade record. If the information is not immediately available, TTMT retries automatically with increasing wait times. This ensures your performance statistics are always accurate, even when closures happen outside TTMT's direct control.

Automatic Recovery From Disconnections ​

When a connection drops, TTMT follows a structured recovery sequence. No manual intervention is required.

Recovery Sequence ​

Reconnection Strategy ​

TTMT retries automatically with increasing wait times between attempts, starting quickly and gradually slowing down. Brief reconnect blips and short cooldowns are normal and handled silently -- they are not surfaced as errors. Most disconnections resolve within the first few attempts. Only a sustained failure, after retries have been exhausted, prompts you to act (via the Reconnect button described above).

What Happens to Existing Positions During Disconnection ​

The stop-loss and take-profit levels already placed on your positions live on the broker, so they keep protecting you while TTMT is briefly disconnected:

  • Stop-loss and take-profit orders remain active on the broker.
  • Breakeven stop losses that were already applied remain in place.
  • Broker-managed trailing (where your provider and broker support it) continues to trail server-side.

The thing lost during a disconnection is live management — new signal processing, breakeven moves, and redistribution all resume once TTMT reconnects and resyncs.

Broker-side trailing depends on your provider

On MetaAPI Cloud with a broker that supports it, trailing runs on the broker and keeps trailing even if TTMT drops. On the self-host providers, broker-managed trailing is not supported — it degrades by skipping activation, so do not rely on trailing surviving a disconnection there. See Position Protection for the full behavior.

A closed market is not a disconnection

If a signal arrives while the broker's market is closed, TTMT does not queue it for later — the signal is skipped immediately and no order is placed. Market-closed is a neutral, expected state, not a lost connection. Only genuine disconnections are recovered from; a closed market is simply declined. See Fast Market Conditions.

Frontend Synchronization State ​

The dashboard displays real-time position data that comes from the live connection. When synchronization is delayed or interrupted, the frontend detects this and alerts you.

Synchronization State ​

The frontend tracks whether the position data displayed is current. If the data may be stale:

  1. The synchronization indicator shows the data is not current.
  2. A staleness warning banner appears prominently in the Live View.
  3. Position data is still displayed but marked as potentially outdated.

This prevents you from making decisions based on stale data. When synchronization resumes, the banner clears automatically and the display updates to reflect current state.

Order Fill Recovery ​

When a limit order fills during a disconnection, TTMT needs to discover this after reconnecting. The system uses a 3-layer defense to ensure no fills are missed.

LayerMethodWhen It Runs
1. Live reconnectBroker resync delivers missed eventsImmediately on reconnection
2. Direct query fallbackDirect query to broker's deal/order historyIf live resync misses events
3. Admin alertNotification that manual review is neededIf both automated methods fail

In practice, Layer 1 catches virtually all missed fills. Layer 2 provides a safety net for edge cases. Layer 3 exists for truly exceptional circumstances.

Summary ​

SystemWhat It Protects Against
Single shared connectionRate-limit churn from parallel connections; conflicting feeds
Automatic refreshStale connections, credential expiration, connection leaks
Stale-Position DefenseStale position data during broker resync
3-Level Health CheckService, connection, and broker failures
Position SyncState drift between TTMT and broker
P&L RecoveryPositions closed outside TTMT's awareness
Automatic ReconnectionNetwork interruptions and server restarts
Frontend Sync StateDecisions based on stale data
Order Fill RecoveryLimit order fills missed during disconnection

INFO

All connection resilience systems are automatic. You do not need to configure anything or take manual action when connection issues occur. TTMT will reconnect, resync, and resume on its own. The dashboard health indicators keep you informed of the current state.