What ATR means before you calculate it
ATR stands for Average True Range. It is a volatility measure built from the idea of True Range (TR), which tries to capture how much price moves within a period, including potential gaps from one period to the next.
ATR is not a forecast and it is not a directional signal. It summarizes recent realized variability. When conditions change, the same ATR level can correspond to different environments.
The core formula (TR and ATR)
Most ATR calculations follow this structure:
- Compute True Range (TR) for each period For a given period t, TR is the maximum of three quantities:
- Range: (High_t - Low_t)
- Gap vs prior close (up move): (|High_t - Close_{t-1}|)
- Gap vs prior close (down move): (|Low_t - Close_{t-1}|)
So: [ TR_t = \max\big((High_t - Low_t),\ |High_t - Close_{t-1}|,\ |Low_t - Close_{t-1}|\big) ]
- Average TR over a lookback window to get ATR Let the lookback length be N periods. ATR over those periods can be computed as an average: [ ATR_t = \frac{1}{N} \sum_{i=0}^{N-1} TR_{t-i} ]
Some systems also compute ATR with a smoothing/recency weighting method, but the key data dependency is the same: TR values based on high, low, and the previous close.
Inputs and assumptions needed
To calculate ATR, you need consistent time-period OHLC data (open, high, low, close), or at least high, low, and close for consecutive periods.
Required parameters:
- Timeframe / period definition (e.g., daily bars, 1-hour bars). ATR depends on what “a period” means.
- Lookback length N (e.g., 14 periods is common in practice, but the computation only requires that you choose some N).
- A way to align Close_{t-1} with the current period’s High_t and Low_t. The prior close must come from the immediately preceding period in your dataset.
Assumptions you must state when you compute it:
- Your OHLC prices are based on the same instrument and the same trading session rules.
- You use the same rounding/precision rules as the system you compare against.
- You handle the first period carefully: TR for the first calculable period needs Close_{t-1}, so you cannot compute TR without a prior close.
Small worked example (with explicit assumptions)
Assume you are calculating TR for one period t using a prior period t−1.
Assume:
- Prior close (Close_{t-1} = 1.1000)
- Current high (High_t = 1.1080)
- Current low (Low_t = 1.1020)
Compute the three candidates:
- (High_t - Low_t = 1.1080 - 1.1020 = 0.0060)
- (|High_t - Close_{t-1}| = |1.1080 - 1.1000| = 0.0080)
- (|Low_t - Close_{t-1}| = |1.1020 - 1.1000| = 0.0020)
Then: [ TR_t = \max(0.0060, 0.0080, 0.0020) = 0.0080 ]
If your lookback is N = 3, then you would average (TR_t), (TR_{t-1}), and (TR_{t-2}) to obtain ATR at time t.
Limitations and common failure modes
-
ATR measures magnitude, not direction ATR does not tell you whether price is moving up or down. Two periods can have the same ATR while their direction and structure differ.
-
ATR depends heavily on the chosen timeframe Changing the period length (for example, using 1-hour bars instead of daily bars) changes the TR sequence and therefore ATR. You cannot compare ATR values across timeframes without adjusting for this difference.
-
Lookback length changes “responsiveness” A shorter N reacts faster to recent changes in TR, while a longer N smooths them out. If you use ATR for comparisons, you must compare like with like: same timeframe, same N, same TR definition.
-
Data quality and session alignment can distort TR Because TR uses High, Low, and the prior Close, inconsistencies in how bars are constructed (missing periods, holiday gaps, or different session cutoffs) can create artificial gaps and inflate TR.
-
Historical ATR levels do not guarantee future behavior Even if ATR has risen or fallen in the past, that pattern does not ensure similar future changes. ATR reflects recent realized variability, not a structural rule.
How to verify ATR independently
To verify your ATR calculation, you can independently reproduce it from the same OHLC inputs:
- Choose a specific timeframe and lookback length N.
- For each period, compute (TR_t) exactly as the maximum of the three candidates.
- Average the last N TR values (or apply the same smoothing method your reference platform uses).
- Confirm edge handling: the first TR values requiring Close_{t-1} and the first ATR values requiring enough TR observations.
If your computed ATR differs from a tool you are checking, the most common causes are mismatched timeframe, mismatched N, different TR definition variants (rare but possible), or different smoothing/initialization choices.
One next question to consider
When comparing ATR across sources, ask: Do both calculations use the same timeframe, the same lookback length, and the same smoothing method (if any)?