Trade Frequency Calculator
Normalize the number of entered close events to one, seven and thirty elapsed calendar days inside an explicit start-inclusive, end-exclusive window. The page does not infer active trading days or recommend an activity level.
Enter the window and close events
Choose what one row represents, then enter every qualifying close timestamp inside the same window.
One ISO 8601 timestamp per line with Z or an explicit UTC offset. Every timestamp must fall inside the window.
Observed activity-rate summary
Observed Trade Activity 1.0.0.
How observed trade frequency is normalized
Records per 7 calendar days = Entered record count ÷ (Elapsed calendar days ÷ 7)
The start timestamp is included and the end timestamp is excluded. This makes adjacent windows composable without double-counting a close at the shared boundary.
One-, seven- and thirty-day rates are simple elapsed-time normalizations of the same entered count. No holidays, sessions or active-day schedule are inferred.
Worked example from the audited fixture
How to interpret the result
Three records per seven calendar days is an elapsed-time normalization of this entered 14-day sample, not an active-session rate or target activity rate. Weekends remain in the denominator. Changing the record basis, observation window, missing closes or duplicate rows can materially alter the result.
Assumptions and limits
- The page cannot determine whether your export treats partial exits or reversals as separate financial-result operations.
- A short window can produce a large and unstable normalized rate.
- Missing, duplicated or out-of-window timestamps directly distort the result.
- Calendar-day normalization includes weekends and other inactive periods.
- Trade frequency alone does not establish overtrading, quality, profitability or future performance.
Frequently asked questions
- It is the count of entered close events divided by the exact elapsed calendar time in the entered observation window.
- A fully closed position and a financial-result operation such as a partial exit are different counting units and should not be mixed.
- No. The start is included and the end is excluded, preventing a boundary close from being counted in two adjacent windows.
- No. The model uses elapsed calendar time and does not infer trading days, holidays or dealer availability.
- The entered record count is divided by elapsed calendar days divided by seven.
- Normalizing a small count across a very short elapsed period magnifies the rate and may not describe longer activity.
- No. The result contains no cost, risk, plan, opportunity or performance context and applies no quality threshold.
- No. It validates timestamp format and window membership but cannot compare the sample with a broker statement.
Sources and methodology
- MetaTrader 5 Help — Trading Report — Official trades-per-week reporting context and the financial-result-operation boundary.
- MetaTrader 5 Help — Testing Report — Official distribution context for entries and outcomes by time bucket.
- CFTC — Trading system claims advisory — Official caution on hypothetical and past-performance presentations.
Continue the performance review
Verify trade-history records and charges
Confirm the statement time zone, position boundaries, monetary basis and trading charges before creating the sample.
Risk and affiliate disclosure: Leveraged forex and CFD trading can result in substantial losses. These are affiliate links, so ForexMT4Indicators.com may receive compensation if you register or trade through them, at no additional cost to you. Availability and terms vary by jurisdiction and broker entity.

