Hourly load forecasts served utilities well for decades. When your dispatchable assets were large thermal plants with 30-minute startup curves, a forecast granularity of 60 minutes was tight enough. You had time to react. The physics of large generation matched the resolution of the forecast.
That alignment is gone. A 2 MWh battery can swing from zero to full discharge in under two minutes. A 500 kW solar array drops 40% output in the time it takes a cloud edge to cross a site. ISO settlement intervals in most North American markets are now 15 minutes for real-time dispatch. The physics changed; the forecast granularity needs to follow.
At Voltsynth, we made an early design decision to run all core forecasting at 15-minute resolution. It was not a trivial choice, since the training data requirements go up, inference latency constraints tighten, and post-processing complexity grows. But every time we talk with a DER operator who is still running hourly forecasts, we see the same downstream problems: dispatch decisions that are slightly off-cycle, settlement imbalances that accumulate over the day, and battery cycling patterns that miss the price signal by a quarter interval.
What Actually Happens at the Sub-Hourly Level
The intuition most people have about load is that it moves slowly. A building's HVAC system ramps gradually, industrial loads follow shift schedules, residential consumption follows waking and sleeping patterns. At the feeder level, aggregated load does smooth out considerably. But two things break that smoothness at sub-hourly timescales.
First, distributed solar introduces generation variability that tracks cloud cover rather than human activity patterns. A cumulus field moving across a distribution circuit can cause the net load seen by the substation to oscillate by 10 to 25% over 10 to 15 minute windows. This is not rare in typical midlatitude weather. Hourly forecasts simply average through this and leave your dispatch logic operating on a value that never actually existed in the interval.
Second, flexible loads and batteries have their own 15-minute participation requirements. When a DER aggregator submits a day-ahead schedule to CAISO or PJM, the schedule is in 15-minute blocks. When real-time deviations occur, the settlement imbalance is calculated against 15-minute actuals. If your forecast produced an hourly value of 800 kW, but the first 15-minute interval was 1,050 kW and the second was 550 kW, you have two separate imbalance charges that an hourly view would have told you to ignore.
The Data Requirements Shift
Running 15-minute forecasts is not just a matter of taking an hourly model and resampling the output. The training data architecture changes substantially.
Historical meter data needs to be at 15-minute granularity, which sounds obvious but is a real constraint. Many utility AMI deployments still log at 60-minute intervals by default, and some older commercial meter points report even less frequently. Before we can train a useful model for a new customer site, we go through a data audit to understand what resolution is actually available and how long the clean history runs. For a mid-size commercial and industrial portfolio in a Western interconnection market, the answer is usually several years of reliable 15-minute data from smart meters, which is sufficient. For smaller utility co-ops or sites that recently upgraded metering infrastructure, the history is shorter and we need to handle that in the model architecture.
Weather features also need to match. Solar irradiance forecasts from numerical weather prediction models like HRRR or GFS are available at sub-hourly temporal resolution, and we align those to the same 15-minute grid as the load history. Temperature, cloud cover index, and wind speed for sites with wind DER participation all come in on the same cadence.
Temporal Alignment with Settlement and Dispatch
The most direct operational argument for 15-minute forecasting is settlement alignment. In real-time energy markets that use 15-minute intervals, your revenue depends on how close your actual output is to your scheduled position in each 15-minute interval. If your dispatch optimization is operating on hourly forecasts that it then divides by four to get sub-hourly targets, you are introducing systematic error in every interval where load or generation is non-uniform across the hour.
Consider a scenario we worked through with a DER aggregation operator in the Pacific Northwest in early 2025. They were running a portfolio of roughly 18 MW of commercial building flexibility and 4 MW of behind-the-meter battery storage. Their existing dispatch logic used an hourly load forecast as input. During a day with a partly cloudy afternoon, the hourly forecast showed 16 MW net load from 2 PM to 3 PM. The actual pattern was 19 MW in the first two 15-minute intervals, then 13 MW in the last two as cloud cover broke. Their batteries were dispatched based on the flat hourly value and missed the peak event entirely in the 2:00 and 2:15 intervals. The imbalance charge for that single hour exceeded their planned revenue for the afternoon period.
We are not saying hourly forecasting is useless. For day-ahead planning and capacity resource adequacy assessments, hourly or even 4-hour block forecasts are appropriate and sufficient. The issue is specifically in real-time dispatch contexts where settlement is sub-hourly and asset response times are measured in minutes.
Model Architecture at 15-Minute Resolution
The models we use for 15-minute DER forecasting are primarily gradient-boosted tree ensembles with temporal features engineered at both the 15-minute and hourly level. We found that purely sequence models like LSTMs can capture temporal autocorrelation well but are slower to retrain and less interpretable when something goes wrong at a specific time-of-day or calendar pattern. Gradient boosting with careful feature engineering handles the periodicity (time-of-day, day-of-week, calendar holiday flags) explicitly and gives us more control over how much weight each feature type gets per site.
We also run separate models per asset type where the portfolio is mixed. A forecast for a feeder that is mostly industrial load looks different from a forecast for a predominantly residential feeder with rooftop solar, and blending both into a single model tends to underfit the dynamics of each. At 15-minute resolution, those differences are more pronounced than they would be at hourly, which justifies the per-segment approach.
Forecast uncertainty is output as a quantile range, not just a point estimate. For dispatch optimization, the P10 to P90 spread on a 15-minute forecast tells the optimizer how much flexibility to hold in reserve during uncertain intervals. A tight distribution means the system can commit batteries more aggressively. A wide spread in a period with variable cloud cover means holding back capacity that might be needed for frequency response.
What to Watch Out For
Shifting to 15-minute forecasting is worth doing, but it comes with a few practical traps to avoid.
Forecast update frequency matters as much as resolution. A 15-minute forecast that is only refreshed once per hour does not give you much more than an hourly forecast in terms of real-time adaptability. We update rolling forecasts every 15 minutes with the latest available actuals and short-term weather data. This keeps the forecast aligned with what is actually happening on the circuit rather than what was predicted hours ago.
Error compounding across a day is also worth measuring carefully. A 15-minute model that is slightly biased in a consistent direction will show that bias 96 times per day rather than 24. Bias detection and correction need to run continuously in production, not just at model training time.
Finally, 15-minute granularity only helps if your downstream dispatch system can act on it. If your DERMS or EMS has a dispatch cycle that runs every 30 or 60 minutes, the forecast resolution is wasted. The full value of sub-hourly forecasting shows up when the optimization layer is also running at the same cadence, which is exactly the architecture we built Voltsynth around: forecast, optimize, and dispatch on the same 15-minute clock.