daily loss limitrule mechanicsserver timerisk management

Server Time Zones and Daily Loss Resets: Why Your Daily Limit Disappears at the Wrong Hour

Daily loss limits reset on the broker's server clock, not the trader's local clock and not the calendar day. A position opened near that boundary can land in a trading day the trader didn't think they were still in — and that's how a legitimate trade turns into a breach.

Portrait of Ryan Tran — Strategy Lead at Glitch Executor
Strategy Lead · Glitch Executor · 2026-09-11 · 8 min read

TL;DR

Daily loss limits reset at a fixed server time set by the broker or platform, which is rarely the trader's local midnight. All six firms we've verified rule data for enforce a daily loss limit, and none of them define the reset in the trader's local time. A trade placed near the boundary can be counted against a day the trader believed was already closed — or already open.

Nobody blows an account by misreading the percentage. The daily loss limit is printed on the challenge page in bold — 3%, 5%, whatever it is — and every trader who buys a challenge has read that number at least once. What isn't printed anywhere near it, usually, is what clock the firm is using to decide when the day starts and ends.

The rule everyone reads, the clock nobody checks

A daily loss limit is simple in concept: lose more than X% of your starting (or prior day's) balance within a single trading day, and the account is done. The complexity isn't the math. It's the definition of "day." Every firm defines its trading day against a server clock — usually tied to the platform's broker feed, not the country the trader lives in and not the country the firm is registered in. That clock rolls over at a fixed hour, and everything before that hour belongs to the old day; everything after belongs to the new one.

If you're trading from a timezone that doesn't line up with the server, your personal sense of "today" and the firm's version of "today" are offset by however many hours separate you. That offset doesn't cause problems most of the time. It causes problems in the last hour or two before the reset, when a trader who thinks they've already banked a loss for the day discovers the day hasn't rolled over yet — or the reverse, where a fresh trade lands inside a day that's about to end and the firm's system treats it as brand new risk on top of an old one.

Where the reset actually happens

The reset isn't a UI event. It's a value the risk engine reads off server time to decide which equity snapshot to compare your current balance against. If that comparison point moves without the trader's mental model moving with it, every calculation downstream is measured against the wrong anchor. This is worse during daylight saving transitions, when a broker's server offset relative to the trader's local clock shifts by an hour twice a year — the reset that used to line up with the end of a trading session no longer does, and nobody sends a notification about it.

None of this means the rule is unfair. A firm has to define a day boundary somehow, and "server time" is at least consistent and auditable. The problem is entirely on the visibility side: the trader's platform shows P&L, not a countdown to the next reset, so the boundary is invisible until the breach notification arrives.

FirmDaily loss limit
Apex Trader Funding2%
FTMO Phase 15%
FundedNext Stellar 2-Step5%
FundingPips Zero3%
GetLeveraged Turbo3%
The5ers High Stakes5%

Every one of the six firms above enforces a daily loss limit. The percentages differ, but the underlying mechanic — a fixed-clock reset that has nothing to do with the trader's calendar day — is the same shape across all of them. Reading the percentage tells you how much room you have. It tells you nothing about when the room refills.

How the mismatch actually kills an account

  1. Trader plans risk around their own local midnight, treating it as the start of a fresh daily allowance.
  2. The firm's server clock hasn't rolled over yet — the "new day" the trader is trading against is still the old one internally.
  3. A trade taken in this window adds its risk to whatever loss already accrued earlier that (server) day, not to a clean slate.
  4. The position moves against the trader by an amount that would be fine on a fresh daily allowance but breaches the limit on the stale one.
  5. The breach notification arrives after the fact, referencing a day boundary the trader never saw.

The trader in this sequence didn't oversize, didn't revenge trade, and didn't ignore the rule. They read the rule correctly and applied it to the wrong clock. That's a tooling gap, not a discipline lapse — and it's exactly the kind of failure that looks, from the outside, indistinguishable from carelessness.

What a pre-trade check can and can't tell you

A risk check that runs before an order goes out can compare your current equity against the firm's daily floor at the moment you're about to trade, using the firm's actual reset boundary rather than your assumption of it. That closes the specific gap in the sequence above: the check doesn't care what time zone you think you're in, it cares what the rule says the day boundary is, right now, on the clock the firm actually uses.

What it can't do is make the boundary intuitive. You still need to know, firm by firm, when your trading day resets — because that number changes what a "safe" position size looks like in the last hour before rollover. A check that fires a warning is more useful than a silent breach. It's not a substitute for knowing the schedule you're actually operating under.

Reading a firm's reset terms before you fund an account

Before paying for a challenge, the reset hour is worth confirming the same way you'd confirm the loss percentage itself — in the firm's own terms, not in a forum post summarizing them. Firms differ in how explicitly they state it, and some describe it in relation to server time without naming a specific UTC offset, which means the actual hour has to be derived from the platform, not assumed from the marketing page.

Citations

FAQ

What time do daily loss limits actually reset?
At a fixed hour on the broker's server clock, defined in the firm's own terms. It is not tied to the trader's local time zone and it is not necessarily midnight anywhere in particular.
Is the reset in my local time or the broker's server time?
Server time. The trading day boundary a firm's risk engine uses is whatever its platform reports, which for most setups is a fixed offset unrelated to where the trader is physically located.
Does daylight saving time change the reset hour?
It can shift the reset's alignment relative to your local clock, even if the server-side hour itself doesn't move, because the offset between your time zone and the server's changes twice a year in most regions.
Do all prop firms enforce a daily loss limit?
Of the six firms with verified rule data here — Apex Trader Funding, FTMO Phase 1, FundedNext Stellar 2-Step, FundingPips Zero, GetLeveraged Turbo, and The5ers High Stakes — all six have one, ranging from 2% to 5%.
What happens if I open a trade right before the reset boundary?
It gets counted against whichever trading day is still active on the server clock at that instant, which may not be the day you think you're in if your local clock and the server clock are offset.
Can a pre-trade risk check fix a misread reset time?
It can stop an order that would breach the limit under the firm's actual boundary, but it doesn't replace knowing that boundary yourself — you still need to confirm the stated reset hour per firm, especially around daylight saving changes.

How we maintain accuracy

Reviewed by Ryan Tran, Strategy Lead, Glitch Executor. Every quantitative claim cites a primary source; firm-rule values come from the firm-rule registry audited quarterly in this repo. No paid placements, no fabricated reviews.

Post last reviewed . Tier 1 surface last reviewed .

Portrait of Ryan Tran — Strategy Lead at Glitch Executor

Written by Ryan Tran

Strategy Lead · Glitch Executor

Writes on prop-firm rule modelling, backtest correctness, and why most "passed challenge" stories don't reproduce.

More from Ryan