Appearance
Are you an LLM? You can read better optimized documentation at /safety-and-reliability/execution-safety.md for this page in Markdown format
Execution Safety
Passing validation gets a signal to the starting line; execution is the race. Between TTMT and your broker, every order, modification, and close is wrapped in fault tolerance: an automatic safety pause that stops trading when errors pile up, a speed control that keeps TTMT from overwhelming the broker, smart retries that handle temporary failures, and hard volume caps that override whatever lot size a signal claims. None of it is configurable — it is always on.
Automatic Safety Pause
The automatic safety pause is a per-account mechanism that halts trade execution when too many errors occur in quick succession. This stops TTMT from repeatedly hammering a failing broker, which would waste margin on rejected orders and risk unpredictable behavior.
How It Works
While the safety pause is open, new signals are queued, not failed. They wait for the pause to cycle through its cooldown into the testing phase, and retries resume automatically once trading recovers. Nothing is silently dropped.
Trip Thresholds
| Failure Type | Threshold to Trip | Why |
|---|---|---|
| Temporary failures | 5 consecutive | Network glitches, temporary broker issues |
| Hard rejections | 2 consecutive | Broker refuses the request outright |
Temporary failures are things like network timeouts and server-busy responses; they are expected to resolve on their own, so it takes five in a row to trip the pause. Hard rejections — invalid parameters, account refused — strongly suggest a systemic problem, so two in a row is enough.
Recovery
| Parameter | Value |
|---|---|
| Cooldown (paused state) | 30 seconds |
| Successes to resume (testing) | 2 consecutive |
After 30 seconds in the paused state, TTMT moves to a testing phase and lets a limited number of operations through. Two consecutive successes resume normal trading. Any failure during testing sends it back to the paused state for another 30-second cooldown.
What Does Not Trip the Pause
Not every broker error means the connection is broken. Three kinds of error are excluded from tripping the safety pause because they are expected or environmental:
- Position or order not found — the thing you were modifying is already gone. Nothing to fix; counting it would lock up your account during normal cleanup.
- Market closed — the market is not open. The order is held, not failed.
- Rate limited — the broker asked TTMT to slow down. TTMT backs off and waits; this is not a real failure.
WARNING
Position-not-found, market-closed, and rate-limited responses never trip the automatic safety pause. They are expected outcomes, not broker failures. Counting them would freeze your account during ordinary operation — for example, when many orders fill in the same second and a few "not found yet" responses arrive in parallel.
Per-Account Isolation
Each MetaTrader account has its own independent safety pause. If your Demo account's broker is having issues, your Live account keeps trading normally. Problems on one account never cascade to another.
TIP
The safety pause is visible in the dashboard header under the Trading Status indicator. A yellow or red indicator means the pause may be active or in a recovery test.
Global Broker Health Monitor
While the automatic safety pause is per-account, the Global Broker Health Monitor watches for patterns across all of your accounts.
| Parameter | Value |
|---|---|
| Failure threshold | 3 failures across any account |
| Pause duration | 60 seconds |
| Scope | All accounts on the same broker |
If 3 failures occur across any combination of accounts within a short window, the monitor pauses all trading for 60 seconds — catching broker-wide outages faster than waiting for individual safety pauses to activate.
Broker health is not a single yes/no flag. TTMT treats a connection as healthy only when it is connected, connected to the broker, receiving live prices, and in sync. Any one of those failing means the connection cannot be trusted. The Connection Resilience page covers that composite health model in full.
Why Both?
The per-account safety pause handles account-specific problems (wrong credentials, a symbol the broker won't trade). The global monitor handles broker-wide problems (a maintenance window, server overload). Together, they cover both failure modes.
Speed Control
Your broker has rate limits. Exceeding them causes rejections, which trip safety pauses, which halt trading. The speed control prevents this cascade by controlling the flow of operations.
| Parameter | Value |
|---|---|
| Max concurrent operations | 5 |
| Minimum gap between operations | 200ms |
| Processing order | First-come-first-served with priority support |
All broker operations — placing orders, modifying positions, closing positions, querying state — go through the speed control. If 5 operations are already in flight, new ones wait their turn. The minimum gap prevents burst patterns that some brokers reject.
Priority Levels
Not all operations are equal. The speed control supports priority levels so capital-protecting work never waits behind routine queries:
| Priority | Operations |
|---|---|
| High | Position close, breakeven modification, stop-loss update |
| Normal | New order placement, take-profit modification |
| Low | Position queries, symbol info, balance checks |
Smart Retries
When a broker operation fails, TTMT decides whether and how to retry it. Different operation types retry differently, because the cost of a delay varies. Breakeven modifications retry fastest, because moving the stop loss to entry after a take-profit hit is capital-protecting — every second of delay is a second a reversal could turn a winner into a loser. Read-only queries retry slowest, because nobody loses money if a balance check is a little late.
Across operations, the pattern is the same: a short initial wait, doubling between attempts, up to a ceiling. A breakeven retry might go 200ms → 400ms → 800ms → 1.6s → 2s (capped); a new order placement might go 1s → 2s → 4s. The increasing wait avoids hammering a system that is already struggling.
INFO
The exact delays and attempt counts differ per operation, and TTMT tunes them internally — you do not configure them. The takeaway is the principle: protective operations are aggressive and fast, routine operations are patient, and nothing retries forever.
How TTMT Classifies Errors
Every broker error is routed through a single classifier — not scattered, inconsistent logic spread across the system. That classifier sorts each error into a precise category and decides the response. There are more than a dozen categories underneath; the table below groups them by what they mean for your trade.
| What you'd see / cause | Retried? | Plain meaning |
|---|---|---|
| Temporary glitch (timeout, server busy, requote) | Yes | Should clear on its own |
| Connection dropped | Yes, after reconnect | Live feed lost; reconnect, then retry |
| Too many requests (rate limited) | Yes, longer wait | Backed off; not a real failure — does not trip the safety pause |
| Market closed | No, queued | Held until the market reopens |
| Position or order not found | No | Already gone; nothing to do — does not trip the safety pause |
| Invalid stops (SL/TP at or past price) | No | Broker refused the stop level |
| Symbol disabled for trading | No | Broker won't trade this symbol right now |
| Credentials expired | Yes, with fresh credentials | Re-authenticates, then retries |
| Insufficient funds | No | Not enough free margin or balance — surfaced to you |
| Uncertain outcome | Special — re-checks first | Couldn't confirm the order landed; TTMT re-probes the broker before deciding |
| Safety pause active | Yes, once the pause clears | Queued behind the automatic safety pause |
| Permanent rejection | No | A genuine refusal; the operation fails and is logged |
| Unrecognized | Cautious | Logged for review |
This single-classifier design is the genuine architectural point: every part of TTMT that touches a broker error reacts to it the same way, so behavior is consistent no matter which operation raised it.
Selected Error Codes
A small sample of how specific MetaTrader codes map to the categories above:
| MT5 Code | Meaning | Category |
|---|---|---|
| 10004 | Requote | Temporary glitch |
| 10006 | Request rejected | Permanent rejection |
| 10010 | Request confirmed | Success |
| 10013 | Invalid request | Permanent rejection |
| 10014 | Invalid volume | Permanent rejection |
| 10016 | Invalid stops | Invalid stops |
| 10018 | Market closed | Market closed |
| 10019 | Insufficient funds | Insufficient funds |
| 10024 | Too many requests | Rate limited |
| 10030 | Order already filled | Permanent rejection |
| -2 | Position not found | Position or order not found |
| 4753 | Position not found (variant) | Position or order not found |
TIP
The full plain-language list of what each error means and what to do about it lives on the Error Messages reference.
Avoiding Duplicate Orders
Some broker calls finish in an uncertain state — a network hiccup mid-request leaves TTMT unable to confirm whether the order actually landed. Blindly retrying could open the same position twice.
TTMT handles this with a dedicated "uncertain outcome" path. Instead of resubmitting, it re-checks the broker for an existing order first. If the order already landed during the glitch, TTMT does nothing further. If it did not, TTMT places it. A momentary network blip never doubles your exposure.
Volume Caps
This is one of TTMT's most important safety features: the lot size in a Telegram signal is never used. Every trade's volume is calculated independently from your settings.
Why Signal Volume Is Ignored
Signal providers often include lot sizes (for example, "Buy XAUUSD 5.0 lots"). These numbers are meaningless for your account because:
- The provider's account size is different from yours.
- The provider's risk tolerance is different from yours.
- Some providers exaggerate volumes for marketing.
- A single typo in the volume could be catastrophic.
TTMT sizes each trade from your fixed lot setting, then splits that total across your entry layers.
Hard Volume Cap
Even after calculating from your settings, TTMT enforces a fixed 5.0-lot maximum on the total size of any single trade. This is a platform safety backstop — it is always on and is not something you configure.
This cap is non-negotiable. Even if your total exceeds 5.0 lots because of a fixed lot set too large — or a configuration error that computes 12 lots — the total is clamped to 5.0 lots.
Higher internal ceilings exist for special account configurations, but every standard account is capped at 5.0 lots.
Per-Asset Overrides
You can set per-asset-class maximum volumes that are even more restrictive than the 5.0-lot platform cap (for example, 0.50 lots on gold). Per-asset caps can only make the limit lower, never higher.
DANGER
The lot size in a Telegram signal is never used. Your settings and the hard caps decide position size — always. A signal that says "Buy XAUUSD 5.0 lots" when your settings compute 0.4 lots will trade 0.4 lots.
How These Systems Work Together
The execution-safety systems are not independent silos — they form one integrated defense:
- The automatic safety pause decides whether trading is allowed.
- Broker health checks for broker-wide issues.
- Volume caps constrain position size.
- Speed control manages operation flow.
- Error classification determines the response to any failure.
- Smart retries handle retriable failures with increasing wait times.
- Successes feed back into safety-pause recovery.
Related Pages
- Signal Validation — the checks that run before execution
- Risk Limits — the daily-loss halt, a different mechanism from the automatic safety pause
- Connection Resilience — the broker-health model behind the global monitor
- Position Protection — what happens after execution
- Error Messages — the full plain-language error reference