Why does my ping to my broker spike at certain times of day?
The short answer
This page explains why ping, the time data takes to your broker and back, spikes at certain times of day. A spike while you trade means each order waits longer and your chart can lag. Busy paths make data wait, so log your readings hourly.
Busy hours make data wait in line, so ping can rise while you trade.
Ping is the time data takes to go there and back. It rises when data waits in line on a busy connection. So the same order can take longer at a busy hour than a quiet one.
Some of your delay never changes, because distance sets a minimum. The rest moves with how busy the path is, and only that share changes with the hour. The panel works out the minimum for any two of our cities.
The maths of ping
01
Your broker’s distance sets a minimum time for every order
Light in a cable travels about 200 km every millisecond. Your order goes there and back, so every 1,000 km adds at least 10 ms.
What it means for youPhysical distance dictates your latency floor. Fibre travel times remain constant regardless of routing tools.
minimum there and back (ms) = distance (km) ÷ 100
02
One lost piece of data makes everything wait
When a packet drops, your platform pauses while requesting a retransmission across the full distance. Consecutive drops double this waiting penalty. Incoming price ticks stall during the exact seconds volatility peaks.
wait 1× → 2× → 4× → 8×
03
Our server in your broker’s city recovers lost data locally
Our server in your broker’s city opens the final connection to your broker. On a quiet connection, a repeat loss doesn’t double the wait.
What it means for youWhen a piece is lost near your broker, our server recovers lost data inside that city instead of from your computer.
distance set by physics · recovery in your broker’s city is ours
Try your own distance
Singapore to London is about 10,850 km in a straight line, so at least 108 ms there and back. No order can reach your broker and hear back in less. Real routes are longer.
We don’t promise lower ping because distance sets the minimum. Local recovery in your broker’s city covers only the connection between our server and your broker. The repeat-loss fix covers the first few tries on a quiet connection, after the first repeat try.
A router is a computer that passes data along. When more data arrives than it can send on at once, the data waits in line.
The internet standards body notes that too much waiting adds unwanted delay. That waiting is the extra delay you see at busy hours.
Your data crosses your own line, your provider’s network and your broker’s. Any of them can be the busy one, and one ping number does not say which. That is why the log below includes a trace.
Lost data adds more delay. Your platform waits about as long as data takes to go there and back, then sends the lost piece again.
If that try is lost too, the wait doubles, and everything behind it waits as well. That is when an order can time out or a connection can drop.
A day of hourly readings shows when your delay rises.
- 01
Get your broker’s server address
Follow check ping to your broker’s server to read it from your terminal or your computer.
- 02
Ping it every hour for a working day
On Windows, run
ping /n 30 BROKER_ADDRESS. On macOS or Linux, runping -c 30 BROKER_ADDRESS.Write down the lowest, highest and average time, and how many replies were lost. The rows show which hours your delay rises.
- 03
Note what else was using your line
Beside each reading, jot down any call, download or backtest that was running. If the spikes match them, the cause is on your own line.
- 04
Trace the path at your slowest hour
Run
tracert BROKER_ADDRESSon Windows, ortraceroute BROKER_ADDRESSon macOS and Linux. Do the same at a quiet hour and compare the rows. The row where the times jump shows where the busy router is.A row of asterisks means that router did not reply. That is not a fault by itself.
- 05
Repeat on a second day
One day can mislead. A pattern that shows on two days is worth acting on.
Your log points to the cause, so you fix the right thing.
Match the pattern in your log to a likely cause and a next step.
| What you see | What it suggests | What to try next |
|---|---|---|
| Ping rises at the same hours every day | A recurring busy period on your line or on the path | Note what else uses your line then, and trace the path at that hour |
| Ping rises only around scheduled releases | A busy router on the path that ping cannot pinpoint | Trace the path at that hour and see where the times jump |
| Ping stays flat while the platform hangs | The delay is not on the path ping measures | Look at your broker’s server and your platform next |
These are readings to test, not diagnoses. Ping tests the path to an address, not your broker’s trading system. The session overlap calculator shows session times in your time zone.
A spike that lines up with news hits the moment that matters most.
To check, line up your log with the release time. Check the date on the publisher’s own calendar, then convert the time to your clock.
Dates move. The US employment report schedule puts 2026 releases on a Friday, except one Wednesday and one Thursday.
The table gives that release time in UTC, so you can match it to your log.
| US clocks | Runs from | Release time in UTC |
|---|---|---|
| Daylight saving (UTC−4) | Second Sunday in March to first Sunday in November | 12:30 |
| Standard time (UTC−5) | First Sunday in November to second Sunday in March | 13:30 |
A fixed UTC time for the report is wrong for half the year. The release notice gives the time in US Eastern time.
We can’t clear busy hours, but we recover lost data inside your broker’s city.
A backtest runs on your own machine, so no internet link can lose a piece of data during a news release. In live trading, one lost piece holds up every price update and order behind it. Everything waits while your computer sends it again across the world.
Our server in your broker’s city opens a separate local connection to your broker. If data drops on that link, our server recovers it inside that city.
Your order waits on that short local link instead of the whole way. Trading ports go first when a server is busy, and broker addresses stay warm in memory.
Data lost between you and our server is recovered between those two. We don’t promise lower ping. Distance sets the minimum. Nothing we do clears the waiting on your line or on the rest of the path.
You cannot paste four values into your platform while your chart is already frozen in a live trade. Set it up today while the market is calm. Then time it on your own screen during the next release.
A ping test never goes through Traders Proxy, so it reads the same with or without us. If our server in your broker’s city is unreachable, your platform shows an error and your dashboard asks before using another city. If your broker prohibits proxies, don’t use one.
Keep going
- Run the connection checkTime a chart load without us and then with us.
- Session overlap calculatorSee session times in your time zone.
Frequently asked questions
How often should I ping to see a daily pattern?
Once an hour across a working day is enough to show a daily pattern. Repeat it on a second day, because one day can mislead.
Is ping lower after hours?
It can be, if the busy network on the path quiets down. We have no measurement for any broker to quote, so log your own and see.
Does a spike at a news release mean my line is at fault?
Not necessarily. Ping tests the path, not your broker’s trading system, so a busy server can be slow while ping looks normal.
Will Traders Proxy remove the spikes?
No. A ping test never goes through it, and it cannot clear the waiting on your line. Instead, our server opens a local connection in your broker’s city and recovers lost data there.
Does a VPS in my broker’s city avoid the spikes on my home line?
It takes your home line out of the path, so you measure the VPS’s line instead. You then trade on a remote desktop. Traders Proxy or a trading VPS sets the two side by side.
Field reports · Verified forum threads
Real forum reports, what our system does, and where it stops.
Every quote below links to the forum thread or vendor guide where it appeared. Underneath each quote, see which parts of our system work together on it and where our server stops.
MQL5.com bans addresses or whole hosting subnets so downloads, MQL5 login and Market fail
“everything was working yesterday ... I cannot even get to the website download.mql5.com as I get connection refused. I have tried 3 different computers.”
Why a proxy can backfire here. No claim about address reputation.
Where it stops. Our server address is shared by people on a Traders Proxy plan in that city. If MQL5.com blocks a hosting range, Market downloads can fail.
cTrader Desktop says 'Connection error' while cTrader Web and the phone app log in fine
“I then downloaded ctrader from the ctrader website directly and it log in perfecly fine but the FTMO branded Ctrader Desktop Verson downloanded from the FTMO website is giving an error.”
Why a proxy does not change this. Traders Proxy doesn't repair login problems caused by Windows updates or an out-of-date platform. Update the platform first.
Where it stops. Do not sell the proxy as a fix for 'Desktop won't log in but Web works'.
cTrader slow or awkward for local-machine or tooling reasons, not network (UI stalls, Mac over remote desktop, Windows-only CLI, Open API apps)
“You might not have enough memory to support the use of cTrader, Windows 10 on Boot Camp and Mac OXs all together.”
Why a proxy does not change this. Traders Proxy doesn't change your computer's speed or the tools your platform offers.
Where it stops. Do not use these threads as proof for any site claim (two of the four cited links do not carry the quoted text).
Terminal stays disconnected until 'Rescan servers' or a restart and switches to a slower access point
“we have had a small number of clients who are experiencing random MT4 disconnects that do not reconnect until the MT4 terminal is restarted.”
Why a proxy does not change this. If one of your broker's servers doesn't answer, our server gives up on it quickly and tells your platform straight away, so it can try another.
- Unanswered broker server gives up fast and reportsBoundary
Where it stops. What your platform tries next after a failed server is up to the platform. We cannot revive a terminal that has stopped trying to reconnect.
Sources
- IETF standard 7567, recommendations on managing waiting lines at routersChecked
- IETF standard 6298, computing the wait before lost data is sent againChecked
- M2 Optics, latency in single-mode fibre (light covers about 200 km each millisecond)Checked
- BLS, schedule of releases for the Employment SituationChecked
- BLS, Employment Situation news release (release time in Eastern time)Checked
- NIST, daylight saving time in the USChecked
- Wikipedia, Eastern Time Zone (UTC offsets)Checked
- Microsoft, ping command referenceChecked
- SS64, macOS ping command referenceChecked
- Microsoft, tracert command referenceChecked
- SS64, macOS traceroute command referenceChecked