Weather is the single highest-variance input on a concrete pour day. The mix design can be perfect, the crew can be certified, the line items can be tight — and one uncaught rain shower inside the cure window still tears the slab out and turns a profitable pour into a callback. This guide walks through the four stages a concrete dispatcher actually uses to read the weather and act on it — rain-delay logic, slump-window math, the per-row forecast that paints the dispatch board, and the typed /api/weather/forecast flow that feeds every pour row a single, deterministic weather call.
1. Why weather matters in concrete scheduling
Concrete is a pour-then-cure material, which means the forecast that matters is not the five-day outlook the homeowner can read on a phone app — it is the hour-by-hour read of the four-hour cure window on the morning of the slab. Rain inside that window scours the surface, ruins the finish, and forces a tear-out the homeowner will not pay for. A forecast that turns wet inside the cure window is a pushout, not a gamble — the pour moves a day, the crew rolls to the next ticket, and the homeowner gets a call before the truck is loaded.
Temperature is the other half of the check. A 90°F+ day shortens the slump window — the working time between the truck arriving and the slab going off — from ninety minutes to forty-five. Cold mornings do the inverse: set time stretches, blankets go on the slab overnight, and the cure-window checklist grows. Weather is the single highest-variance input on a pour day, and the forecast the dispatcher reads at five in the morning has to land next to the line items on the pour row — which is exactly what the dispatch board in the dashboard is built to do.
2. Rain delay and slump window logic — the four categories
The PourSmart dispatch system collapses the forecast into four categories a pour row can render as a single badge: ok, rain, freeze, and heat. Each one maps to a real field decision: an ok badge is a green-light pour, a rain badge is a pushout for any pour whose cure window overlaps the wet band, a freeze badge forces blankets on the slab overnight, and a heat badge collapses the slump window and demands a retarder, a chilled mix, or an extra hand on the screed.
Rain during the cure window is the most expensive forecast miss a dispatcher can make — the tear-out cost lands on the contractor, not the homeowner. The slump window collapse is the second-most-expensive: a finisher who loses the slab to a hot-load has to demo and re-pour on the same ticket, and the truck bill grows while the second crew rotates in. Freeze below 32°F overnight forces blankets regardless of the day-of pour temperature, and heat index above 90°F collapses the slump window from ninety minutes to forty-five — the same window a cool morning gives you back at full length. Every pour row reads off a single tuple of tempF, precipChance, windMph, shortForecast, and category, and that tuple is computed once per row at the time the board paints, not threaded through a text chain at seven a.m.
3. Integrating forecasts into the dispatch board
The dispatch board paints one row per pour, top-to-bottom in time-on-site order. Each row carries the crew assignment, the line items reused from the original quote, and a weather badge derived from the per-row forecast. The dispatcher reads the board top to bottom — rain-delay pushes first, then the multi-pour day, then the standalone slab — and the weather call on every row answers the same question from the same data source. There is no separate weather tab, no spreadsheet overlay, and no group-text thread asking “are we good to pour” at seven a.m.
The badge has to live on the row because the rain check is a row-level decision. A two-pour day with one row in the rain band and one row in the clear needs two different actions: the wet row pushes, the clear row rolls. Treating the weather check as a board-level summary collapses the two into one wrong answer. PourSmart fetches one forecast per row, scoped by lat/lng and pour date, and renders a badge on each row from the same payload shape — a fail in one row does not take the board down, and a stale badge on a single row does not propagate to the rest. The dispatch workflow field guide walks through how that per-row surface ties into the crew-split and time-on-site math that runs the rest of the morning.
The same per-row discipline feeds a parallel three-day outlook handled by a separate /api/weathersurface for the week-ahead planning view — the snapshot endpoint and the three-day endpoint are intentionally split, because the five a.m. decision needs a single-date deterministic answer and the Monday planning pass needs a multi-date range. Two endpoints, two cadences, one badge per pour. That is the contract the dispatch board on the dispatch surface in the dashboard renders against, and the one the dispatcher trusts at five a.m.
4. PourSmart’s /api/weather/forecast flow
The per-row forecast is served by a single typed endpoint: GET /api/weather/forecast?lat=..&lng=..&date=YYYY-MM-DD (a zipalternative is accepted when the address only ships a postal code). The dispatcher passes the lat/lng from the pour’s address and the date from the scheduled pour, and the handler returns a typed payload every pour row reads back as: tempF, precipChance, windMph, shortForecast, and category. The category is what drives the badge; the rest is what drives the badge’s tooltip and the row’s “why this forecast” note.
The contract is zod-validated at the edge of the endpoint, so the dispatcher cannot accidentally render a malformed payload as a badge — the categories collapse to the four the board knows how to paint, and anything outside that set fails the row-level render rather than letting drift propagate across the board. Per-row resilience is built into the fetch shape itself: one row’s timeout, one row’s outage, or one row’s upstream NOAA blip degrades that single row’s badge to a neutral “weather pending” state and leaves the rest of the board paintable. The WeatherForecastOutput type closes the drift at compile time, so the dispatch board can never render a payload shape upstream has stopped sending.
Generic routing tools — the kind a JobNimbus-style routing list or a flat technician-routing app — carry a per-day, per-route forecast at best, not a per-pour, per-row feed keyed by address and pour date. A dispatcher running the morning on a routing list ends up re-typing the lat/lng into a phone weather app while the first truck is loading. PourSmart vs JobNimbus walks through why a routing list does not translate to a finisher-certified concrete crew, and how a per-row forecast feed — the kind /api/weather/forecastserves — is the missing layer a finisher-certified crew needs at five a.m.
Bring a real pour into PourSmart.
Pick a pour you have bid recently and run it through the calculator — see the breakdown PourSmart produces in seconds, before you commit.