VPS Hygiene for MT5: A Weekend Restart Routine That Does Not Bite You on Monday

A Windows VPS running MetaTrader 5 for weeks without a break tends to degrade slowly: memory creeps up, log and tester folders grow, Windows queues updates and then picks its own moment to reboot. A planned weekly restart, done while markets are closed, removes most of that risk. Done carelessly, it creates new risk: terminals that do not come back, EAs that start without their settings, or a restart that happens with a position still open.

This post describes a restart routine built around one principle: check before, change carefully, verify after.

Why a weekly restart at all?

Illustrative observations from long-running hosts:

• Terminal memory use rising from ~350 MB to 1 GB+ over several weeks with many charts and indicators.
• logs and Tester folders adding several GB a month on a busy machine.
• Windows Update rebooting the VPS mid-week because a deadline passed.

A controlled restart on the weekend clears memory, applies pending updates at a time you chose, and gives you a regular checkpoint to confirm everything still starts cleanly.

Pick the window

Choose a slot when your instruments are closed and well away from the weekly open, for example Sunday early afternoon (illustrative; check your broker's server time and any instruments that trade at weekends). Write the window down and make the routine refuse to run outside it.

Step 1: the pre-flight gate

Nothing restarts unless every check passes. If any check fails, the routine stops and tells you why.

1. Inside the window? Day and hour match the plan.
2. No hold flag? A simple file such as C:\desk\HOLD lets you veto the restart this week without editing anything.
3. No open exposure that should not be there. Most weekend restarts are only safe with no open positions and no pending orders on the accounts this host runs, unless you have consciously decided otherwise.
4. No open incident. If something is already wrong, a restart can destroy the evidence. Fix or record it first.
5. Enough disk space. Updates and logs need room; abort below a threshold such as 10 GB free (illustrative).

Record the result of each check in a dated log, whether it passed or failed.

Step 2: capture the "before" picture

Before changing anything, write a short host snapshot: running terminals and their memory, each terminal's build number, free disk, uptime, and the hash of each EA's .set file. This is what you compare against afterwards. Without it, "it looks fine" is a guess.

Step 3: close terminals gracefully, one at a time

Killing terminal64.exe works, but it skips the terminal's own shutdown, where it saves chart and profile state. Ask each terminal to close normally, wait a reasonable time (30 s, illustrative), and only force-stop one that hangs. Log every forced stop. Repeated forced stops on the same terminal are worth investigating.

Close terminals one at a time rather than all at once, so the log tells you which one misbehaved.

Step 4: housekeeping

While everything is closed:

• Archive old logs, then delete them, in that order. Delete a file only after it is safely in the archive. One trap: MT5 names log files by date ( 20260901.log ), so logs from different terminals share file names. Archive per terminal, or they overwrite each other inside a single archive.
• Clear temp folders.
• Leave the Tester cache alone unless you have a reason; it is cheap to keep and slow to rebuild.

Step 5: restart and bring terminals back

Reboot the VPS so Windows applies updates you have already approved. After reboot:

• The trading user needs to log on automatically, or terminals will not start. Test this once by hand.
• Start terminals in a fixed order with a pause between each (20–30 s, illustrative) so they do not all download history at the same moment.
• If you run several installs, use portable mode consistently so each terminal finds its own data folder.

Step 6: verify, do not assume

Within 30–60 minutes of the restart (illustrative), compare against the "before" picture:

Anything that does not match is either fixed now, while markets are closed, or written up as an incident. The worst outcome is discovering a missing EA at Monday's open.

When terminal builds change

MetaTrader updates itself. A restart is often when a new build appears. Treat a build change as a change:

• Note old and new build numbers.
• If you run several terminals, consider letting one demo terminal take the new build first and watch it for a session before the live ones follow.
• Do not run mixed builds across terminals for long without knowing why.

A one-page checklist

Before: window ✔ · hold flag absent ✔ · exposure as expected ✔ · no open incident ✔ · disk OK ✔ · snapshot written ✔ During: graceful close one by one ✔ · forced stops logged ✔ · logs archived, then deleted ✔ · reboot ✔ After: terminals up ✔ · servers correct ✔ · AutoTrading on ✔ · EAs on correct charts ✔ · .set hashes match ✔ · builds noted ✔ · heartbeats green ✔

Summary

A weekly restart is maintenance, not a ritual. Gate it, snapshot before, close gently, archive before deleting, and verify against the snapshot afterwards. The routine takes minutes once it is written down, and it turns Monday morning from a surprise into a formality.

Virtual Risk Desk

All figures, times and thresholds are illustrative. Test any routine on a demo environment first. This is educational content about operations, not trading or investment advice.