Skip to main content
Blog/Reliability

MT5 disconnect alerts and stale terminal monitoring

A stale terminal is dangerous because the dashboard may stop seeing the account while positions remain open. Heartbeat monitoring turns silence into an alert.

Reliability7 min readJul 3, 2026
By xTriel editorial team · Reviewed and updated
Connection state is not data freshness: Transport state, Last heartbeat, and Escalation.
FIG 01 — Connection state is not data freshness.

MT5 can stop reporting for several reasons: VPS restart, broker disconnect, chart closed, EA removed, network failure or a frozen terminal. If the account has open positions, stale data can hide real risk.

What is a heartbeat?

A heartbeat is the last time the terminal or reporter sent a valid update. If the expected interval is one minute and the last update was eight minutes ago, the account should be marked stale.

Common causes

  • VPS restart or Windows update.
  • Broker server disconnect.
  • MT5 terminal freeze.
  • Reporter EA removed from the chart.
  • Network or firewall issue.

Alert before trust is lost

A stale alert is not the same as a drawdown alert. It says the monitor no longer trusts the data. That deserves attention because the account may still be trading while the dashboard is blind.

Response workflow

When a stale alert fires, check VPS access, broker connection, terminal status and the chart running the reporter. If the account is near a risk limit, treat the stale event as urgent.

Connected is not the same as current

MT5 can report a connection while the monitoring pipeline has stopped publishing useful account updates. Track two clocks: the terminal’s connection state and the age of the last successfully received heartbeat or account snapshot. A transport flag helps diagnose the cause; freshness determines whether the displayed numbers can still be trusted.

Choose a freshness threshold from the expected reporting interval. If telemetry normally arrives every 15 seconds, a 20-second alert will flap during harmless jitter while a 15-minute alert hides real outages. A practical policy might warn after three missed intervals, escalate after a longer window, and recover only after several consecutive good reports.

Worked incident sequence

At 10:00:00 a terminal publishes equity and positions. At 10:00:15 and 10:00:30 no heartbeat arrives. At 10:00:45 the monitor marks the account stale and sends one warning containing the last-seen time, host and account. At 10:02:00 the terminal reconnects. The system waits for a fresh snapshot, verifies its timestamp, then sends a recovery message. Connection alone does not clear the incident because cached values may still be old.

Design alerts to shorten diagnosis

  • Include account identity, VPS, last heartbeat, age and connection state.
  • Group simultaneous stale accounts by host to reveal a shared VPS outage.
  • Distinguish “terminal disconnected,” “reporter stopped” and “backend cannot receive.”
  • Suppress duplicate pages while retaining an incident history.
  • Monitor the monitor with an external check that does not share the same process.

Run failure drills: close one terminal, block its network, stop its reporter, and stop the entire VPS. Confirm that each failure creates an actionable event and that recovery is recorded. The VPS setup guide reduces shared failure domains, while the multi-account guide explains host-level grouping. Alerting should reduce uncertainty, not merely announce that something is wrong.

Set a service objective

Define the monitoring promise in measurable terms: expected heartbeat interval, warning delay, critical delay and recovery confirmation. Track the percentage of time each account delivered fresh telemetry and the time from a real failure to an operator-visible alert. These measures expose chronic brief outages that an incident count can miss.

Retain state transitions rather than logging every repeated poll. A compact sequence—healthy, stale, disconnected, recovering, healthy—supports incident review and keeps alert volume manageable. After an outage, ask whether the terminal, network, reporter or receiver failed first, whether another system could still page, and whether account risk changed while visibility was lost.

Schedule a synthetic heartbeat from a known test account and alert if the receiver stops observing it. Keep the synthetic path separate from live trading, but make it exercise the same network and ingestion components. This proves the alert path is alive even when production accounts happen to be quiet.

Primary source

Technical reference: official MetaTrader documentation. Broker and prop-firm terms can differ; verify the rules for the exact account you operate.

Turn silence into a signal.

xTriel marks stale MT5 accounts and sends risk alerts when telemetry stops arriving.

Connect MT5