It means the node is operating normally right now. It does not mean your broker, platform, or home connection cannot still be the source of a problem.
Network status
Real-time health for every TradersProxy node — so you always know what the infrastructure looks like before you trade.
All nodes
Active health checks run every 15 seconds from three independent probe points. Status shown below reflects the current EWMA over a 5-minute window.
Historical uptime
last 90 days — April 23, 2026
Two incidents in the last 90 days. One was a brief transit provider issue on Singapore with automatic failover. One was a planned 12-minute maintenance window in Sydney. Total unplanned impact across the network: under 4 minutes.
Recent incidents & changes
All entries in reverse chronological order. Planned maintenance windows are announced 48 hours in advance via the client portal.
-
2026-04-18
Brief packet loss on Singapore node — 3 min Resolved
Transit provider issue upstream of Equinix SG1. Automatic failover activated within 47 seconds; affected sessions migrated to backup node. No manual intervention required. Transit provider confirmed root cause as a BGP route withdrawal; path stabilised and primary node resumed full traffic. -
2026-03-27
Planned maintenance — Sydney SY4 — 12 min Complete
Scheduled kernel update and conntrack table optimisation on the Sydney node. Announced 48 hours prior via portal. Traffic migrated to backup node during the window; all sessions reconnected automatically on completion. -
2026-03-02
Route optimisation pushed globally — 0 downtime No impact
Updated BGP preference weights across all 12 nodes following a network review. APAC paths to broker hubs improved by an average of 4 ms RTT. Deployed rolling with no session interruptions.
How we monitor
Active health checks, every 15 seconds
Every node gets probed from three independent geographic locations every 15 seconds. Probes measure round-trip latency, packet loss, and TCP session establishment time against a set of broker endpoints representative of the node's primary traffic.
Health scoring uses an exponentially weighted moving average (EWMA) over a 5-minute window. Short-term spikes — the kind that happen during NFP or CPI releases when broker ingress queues briefly back up — don't trigger a false degraded status. Sustained degradation does.
If a primary node crosses the degradation threshold, affected accounts automatically migrate to their assigned backup node. The failover happens at the routing layer: your platform sees the session drop and reconnect, typically within 3–8 seconds. No manual switch. No support ticket.
Node hardware metrics — CPU load, memory pressure, NIC queue depth — are collected every 30 seconds. Alerts fire before resource saturation can affect latency. Capacity headroom is maintained at 40% across all nodes during peak trading hours.
Something look wrong?
How to reach us
If your platform is showing an issue that isn't reflected here, or if you want to report something that looks like a network problem, you have two options.
Email: support@tradersproxy.com — include your node region, your broker hostname, and a rough timestamp. That's enough for us to pull the right logs.
Client portal: Log in at the portal and open a support request. Portal tickets give us your account context automatically, which speeds up the diagnosis.
We don't run a live chat. We run a small team that digs into the actual problem rather than farming a ticket queue. Turnaround on support emails is typically under 4 hours during business hours.
Status is useful only if it tells you what to do next.
A healthy node is not just a green light. It is a sign that the route, the relay, and the monitoring stack are behaving the way they should. If something looks wrong here, the important part is whether it is a real network issue or a local setup problem.
Small jitter, maintenance windows, or upstream changes can create a temporary wobble without turning into a full outage.
If a node is red and your own line is stable, send the region, broker hostname, and rough timestamp so we can pull the right logs quickly.
We keep the status page plain for a reason. The goal is not to impress you with uptime theater. The goal is to show whether the path is healthy enough to trust in real use.