GribStream Blog

NOAA reschedules RRFS and REFS operations for October 6, 2026

GribStream | Published May 13, 2026 | Updated Aug 14, 2026 |

rrfs2dfld rrfsprslev refsprslev namconusnest hrrr rap

NOAA/NWS moved operational RRFS and REFS to October 6, 2026 and the parallel feed to August 11, before they replace NAM, SREF, HREF, most HiresW domains, and NAM MOS.

Update, August 14, 2026: NOAA's real-time parallel RRFS and REFS feed is now publishing from its new public S3 distribution. This remains a pre-operational parallel feed: NOAA's scheduled operational implementation remains October 6, 2026 at 12 UTC, subject to the weather-delay conditions below. GribStream's availability of the two deterministic datasets is covered in Pre-operational NOAA RRFS forecasts are now available on GribStream. The individual-member source behind RRFS Ensemble stopped updating during the handoff; GribStream now treats the historical refsprslev dataset as deprecated because the replacement distribution publishes derived REFS products rather than compatible members.

Update, July 27, 2026: NWS revised Service Change Notices 26-48 and 26-47 after this article was published. The real-time parallel NOMADS feed is now expected on or about August 11, 2026, and operational implementation of RRFS and REFS, together with retirement of the affected legacy systems, is now scheduled for October 6, 2026 at 12 UTC. The original announcement called for a June 9 parallel feed and an August 31 production transition.

NOAA/NWS has put a date on one of the biggest regional-model transitions in years: RRFS and REFS are now scheduled to become operational on October 6, 2026, beginning with the 12 UTC cycle.

That same implementation retires a large part of the legacy regional suite: NAM, SREF, HREF, HiresW for CONUS, Alaska, Hawaii, and Puerto Rico, and NAM MOS. The Guam HiresW domain is the major exception called out in the notice.

For GribStream users, this is the point where RRFS stops being only an experimental dataset to watch and becomes the system NOAA is using to consolidate storm-scale regional guidance. If your product, dashboard, forecast comparison, or model workflow still depends on NAM, HREF, SREF, or HiresW, the migration window is no longer hypothetical.

The important dates

There are two dates to track:

August 11, 2026, on or about: NOAA expects a real-time RRFS and REFS feed to become available on NOMADS in parallel paths.
October 6, 2026 at 12 UTC: RRFS and REFS are scheduled for production implementation, and the legacy systems are scheduled for retirement on the same day.

NOAA includes the usual operational caveat: if the date falls under a Critical Weather Day, Enhanced Caution Event, or other significant weather constraint, implementation moves to the next eligible weekday at 12 UTC.

What RRFS changes

RRFS is NOAA's next-generation rapidly updated, convection-allowing regional forecast system. The operational configuration described by NWS is a 3 km North America system with deterministic forecasts and companion ensemble guidance.

The deterministic RRFS schedule is broader than the legacy systems it replaces:

00/06/12/18 UTC cycles: forecast out to 84 hours
other hourly cycles: forecast out to 18 hours
full North America domain: 3 km
CONUS and Alaska subsets: 3 km
Hawaii and Puerto Rico subsets: 2.5 km
fire-weather run: separate relocatable 1.5 km domain

That matters because RRFS is not just a replacement file stream. It changes the baseline model family for short-range, storm-scale workflows: severe convection, aviation weather, precipitation timing, winter hazards, wind guidance, fire-weather diagnostics, and high-resolution regional ML inputs.

What REFS changes

REFS is the ensemble product generation system built around RRFS output. It replaces HREF as the main high-resolution ensemble product family.

The NWS notice says RRFS itself produces five ensemble forecast members through 60 hours for the 00/06/12/18 UTC cycles. REFS then combines output from current and 6-hour-old RRFS deterministic and ensemble cycles. For CONUS and Alaska, REFS also includes two HRRR members from current and 6-hour-old cycles.

The products are the kinds of ensemble fields HREF users already care about: means, spread, probability-matched means, localized probability-matched means, probabilities, ensemble agreement scale products, and CONUS flash-flood recurrence interval exceedance probabilities.

The big customer-facing difference is scope and cadence. REFS runs to 60 hours, compared with HREF's 48 hours, and NWS says REFS will generate products for CONUS, Alaska, Hawaii, and Puerto Rico for every 00/06/12/18 UTC cycle.

What this means on GribStream

GribStream serves the two deterministic RRFS datasets from NOAA's replacement parallel feed:

RRFS 2D Fields: rrfs2dfld
RRFS Pressure Levels: rrfsprslev

Use those two datasets for side-by-side testing, selector discovery, and migration planning. The live GribStream RRFS catalog is the safest place to check exact variables because field availability, levels, and product split matter more than the model name alone.

RRFS Ensemble remains available as a historical reference, but refsprslev is deprecated and is not receiving new forecasts. NOAA's replacement feed exposes ensemble means, spread, probability-matched means, probabilities, and other derived REFS products, but not the compatible individual members this dataset used. We will evaluate those product families as separate GribStream datasets. If NOAA later publishes compatible members, support can be reconsidered through a separate onboarding.

The October 6 12 UTC cycle should be treated as a model-system boundary in your own validation. If you compare RRFS against NAM, NAM Nest, HREF, SREF, or HiresW, keep the cutover date explicit in backtests, alert thresholds, and model-comparison dashboards.

When NOAA completes the transition from the parallel feed to production, GribStream will revalidate the operational products and update support around the stable production catalog. We will keep existing GribStream dataset codes stable where product identity permits, while treating new domains, product groups, and ensemble outputs as explicit additions.

Migration checklist

If you use legacy regional guidance, start the comparison now:

NAM or NAM Nest users: compare pressure-level fields, 2 m temperature, 10 m wind, precipitation, cloud, visibility, ceiling, and storm diagnostics against rrfsprslev and rrfs2dfld.
HREF users: compare ensemble mean, spread, probability, and probability-matched products against REFS as product coverage becomes available.
SREF users: treat this as a higher-resolution ensemble migration, not a one-for-one product rename.
HiresW users: check both domain coverage and variable coverage. The Guam HiresW domain is expected to remain, while CONUS, Alaska, Hawaii, and Puerto Rico are scheduled for retirement.
Operational customers: preserve a side-by-side period before October 6 so thresholds, model blends, and dependent models can be recalibrated.

The practical risk is not only that an old file path disappears. RRFS and REFS are different modeling systems with different physics, domains, cadence, lead-time structure, and ensemble membership. Applications that depend on model-specific behavior should validate forecast behavior, not just request syntax.

Why this is more than a data-feed change

The public weather community is already treating this as a real forecasting transition. NOAA's own testbed writeup frames RRFSv1 and REFS around direct comparisons with NAM, NAM Nest, and HREF, while noting that future MPAS-based RRFS development continues beyond v1. Local forecast teams are also starting to explain the change to viewers; WRAL's coverage, for example, points to small-scale features, precipitation timing, and the loss of familiar NAM behavior in cold-air damming setups.

That is the right way to think about the change. RRFS is a new operational baseline for a class of decisions that used to be split across several regional models. For GribStream customers, the best move is to test early, keep the October 6 boundary visible, and migrate with the exact fields and domains your workflow actually uses.