FXVPS
Get Started
vps windows-server ntp expert-advisors troubleshooting

Time Synchronisation on a Trading VPS: The Clock Problem Nobody Checks

person
FXVPS
Share
Time Synchronisation on a Trading VPS: The Clock Problem Nobody Checks

There is a category of trading bug that survives every round of debugging because nobody thinks to look at it. The EA code is correct. The broker is fine. The VPS has plenty of RAM and a good connection. And yet the news filter fired two minutes late, the scheduled restart landed inside the London open, and the EA’s own log timestamps do not line up with the broker’s journal when you try to reconstruct what happened.

The cause, more often than traders expect, is that the machine’s clock is wrong.

Not wrong by hours — you would notice that. Wrong by fifteen seconds, or ninety, or four minutes. Enough to break a time-based decision, not enough to be obvious. This post explains what a drifting clock does and does not affect, and how to fix it in about ten minutes.

What a Wrong Clock Does Not Break

Start with the reassuring part, because it explains why this problem hides so well.

Your charts are fine. MetaTrader chart times come from the broker’s server, not from your machine. A candle that opens at 09:00 server time opens at 09:00 server time regardless of what Windows thinks the hour is. TimeCurrent() in MQL returns the last known server time, which is also unaffected.

Your fills are fine. Order timestamps are assigned by the broker’s server. Your machine’s opinion of the time has no bearing on when an order was received or at what price it filled.

This is exactly why the problem persists. The most visible parts of the platform look completely normal, so the clock is the last thing anyone suspects.

What a Wrong Clock Definitely Breaks

Local and GMT time functions in MQL. TimeLocal() returns the time on the computer running the terminal. TimeGMT() derives from your machine’s clock and its configured timezone. Any EA that uses either — and a great many do, for session filters and trading-hour windows — inherits your machine’s error directly. An EA told to trade only between 07:00 and 16:00 GMT, running on a clock four minutes fast, opens its window four minutes early. Every day.

News blackout filters. Strategies that pause around scheduled releases compare the current time against an economic calendar. If your clock is ninety seconds slow, your “stop trading two minutes before NFP” rule becomes “stop trading thirty seconds before NFP.” That is the difference between avoiding the release and trading straight into it.

⚠️ Warning: This one has direct financial consequences. Many prop firms enforce news-trading restrictions with a hard window around high-impact releases, and a breach is a rule violation regardless of the trade’s outcome. If your EA’s news filter is running on a drifting clock, your compliance margin is smaller than you think. Our prop firm rules and VPS compliance guide covers the broader picture.

Scheduled tasks. If you use Task Scheduler to restart terminals, run backups, or cycle a platform outside market hours, those tasks fire against the local clock. A machine several minutes off can push a scheduled restart into the edge of a session. Our Task Scheduler automation guide assumes the clock is right.

TLS and certificate validation. Secure connections check certificate validity against the local clock. A clock wrong by a large margin — typically minutes to hours, depending on the service — can cause connection failures that present as mysterious login problems, failed HTTPS requests from an EA’s WebRequest calls, or broken licence checks.

Commercial EA licence servers. Many paid EAs authenticate against a vendor server, and some of those checks are time-sensitive. “The EA suddenly says my licence is invalid” is a support ticket that occasionally resolves to a clock problem.

Log correlation. When something goes wrong and you need to reconstruct events, you compare your terminal’s Experts and Journal logs against the broker’s records. If your timestamps are offset, that reconstruction becomes guesswork — precisely when you need it to be exact, such as disputing a fill.

📊 Key Stat: Windows’ default time synchronisation was designed for domain authentication tolerances, not for trading. Out of the box, a standalone Windows Server can poll a public time source infrequently enough that measurable drift accumulates between syncs. Tightening the poll interval is a registry change that takes two minutes.

Why Clocks Drift on Virtual Machines

Every computer’s clock drifts. The oscillator is not perfect, and small errors accumulate. On physical hardware this is usually slow and undramatic.

Virtual machines have an additional source of error. A VM does not own the physical timer hardware; it receives time through the hypervisor. When the host is busy, or when a VM is paused, migrated or heavily scheduled, the guest’s sense of elapsed time can slip. Modern hypervisors handle this well, and a well-provisioned VPS on dedicated cores drifts far less than an oversubscribed one — which is one more practical argument for dedicated cores over shared vCPU.

Either way, the fix is the same: synchronise regularly against a reliable external source and verify that it is working.

Checking Your Clock in Two Minutes

Open Command Prompt as Administrator on your VPS.

See the current sync status:

w32tm /query /status

Read three fields. Source tells you what the machine is synchronising against. Last Successful Sync Time tells you when it last worked — if that is days ago, you have found your problem. Clock Dispersion gives an estimate of the current error.

See which peers are configured:

w32tm /query /peers

Force an immediate resync:

w32tm /resync /force

Compare against a known-good reference. Open time.is in a browser on the VPS. It reports your machine’s offset from actual time in milliseconds. This is the simplest end-to-end check available and it takes five seconds.

💡 Tip: Do this check on a schedule, not once. A clock that is correct today can drift badly after a host event weeks from now. Add “run w32tm /query /status and glance at the last sync time” to whatever monthly maintenance routine you already have for the VPS.

Fixing It Properly

If the Windows Time service is not syncing reliably, configure it explicitly. From an elevated Command Prompt:

1. Point at reliable time sources. The ,0x9 suffix requests client mode with the configured special poll interval:

w32tm /config /manualpeerlist:"time.windows.com,0x9 pool.ntp.org,0x9" /syncfromflags:manual /reliable:yes /update

2. Make sure the service starts automatically. The Windows Time service is sometimes set to manual start:

sc config w32time start= auto

3. Restart the service and resync:

net stop w32time net start w32time w32tm /resync /force

4. Tighten the poll interval. The default interval between synchronisations is generous. In regedit, navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

Set SpecialPollInterval (a DWORD, in seconds) to something appropriate for trading — 3600 for hourly, or 900 for every fifteen minutes. Hourly is plenty for essentially every retail trading use case. Restart the Windows Time service afterwards.

5. Verify. Run w32tm /query /status again and confirm the source and last sync time are what you expect, then check time.is once more.

✅ Best Practice: Leave your VPS timezone set to UTC and let the terminal display broker server time. Mixing local timezones across a VPS, a broker server and a personal machine is how people end up with off-by-one-hour errors twice a year. If you need to reason about session times, doing it in UTC removes an entire class of mistake — and read our daylight saving time guide for the DST-specific traps, which are separate from clock drift and catch people every March and October.

Where This Sits in Your Setup

Clock synchronisation is not a reason to buy a VPS — it is a reason to configure the one you have correctly. It belongs in the same maintenance category as scheduling Windows updates sensibly and monitoring resource usage.

That said, it interacts with plan choice in one indirect way. A machine under sustained CPU pressure schedules its own processes late, and an EA that receives a tick two hundred milliseconds after it arrived is effectively operating on stale time regardless of how accurate the wall clock is. If you are running many terminals or heavy indicator stacks, the right fix is headroom rather than clock tuning.

Core Plan ($29/mo) — 2GB RAM, 1 vCPU. Fine for a single terminal with a few EAs.

Pro Plan ($39/mo) — 4GB RAM, 2 vCPUs. The sensible level for multiple terminals or heavier automation, where you want certainty that scheduling delay is not masquerading as a timing bug.

Scaling Plan ($79/mo) — 8GB RAM, 4 vCPUs. For multi-account operations where time-sensitive automation runs alongside everything else.

🚀 Try FXVPS free for $1.99 — get 7 days on the Core VPS risk-free. Run the w32tm check on it and see what a properly configured Windows Server looks like. Cancel anytime.

Find the plan that fits your setup at /pricing/, and if you are already running with us, spend ten minutes on the checks above. It is the cheapest reliability improvement available to you.

Frequently Asked Questions

Does my VPS clock affect my MT4 chart times?

No. Chart times and TimeCurrent() come from the broker’s server. What your local clock affects are TimeLocal() and TimeGMT(), which many EAs use for session and news filters, plus Windows-level scheduling and certificate validation.

How far off does the clock have to be before it matters?

It depends entirely on what depends on it. A news blackout filter with a two-minute buffer is compromised by an error approaching two minutes. A session-open filter can be broken by seconds if you trade the open aggressively. For scheduled restarts, minutes matter. There is no universal threshold — sync properly and remove the variable.

Should I set my VPS timezone to my broker’s timezone?

We recommend UTC, with the terminal displaying broker server time as it always does. Setting the machine to a broker’s timezone tends to create confusion during DST transitions, since broker server DST rules and Windows timezone rules do not always change on the same date.

Can a wrong clock cause login failures?

It can. TLS certificate validation checks validity dates against the local clock, so a sufficiently wrong clock can break secure connections — presenting as failed logins, failed WebRequest calls from an EA, or licence check failures rather than as an obvious time error.

Is this a problem specific to VPS hosting?

No, but virtualisation adds a drift mechanism that physical machines do not have, since the guest receives time through the hypervisor. In practice, a properly configured VPS on dedicated cores keeps better time than most home computers — the point is to configure it rather than assume it.