fieldwork
The First 72 Hours After a Hail Event
What storm data actually exists in the days right after a hail event, what does not arrive for months, and how to make early calls you can defend
The window where the data is thinnest
The decisions with the largest effect on a storm job get made in the first three days, and they get made on the worst data anyone will ever have about that storm. That is not a failure of your process. It is the shape of the public record. The fast sources are preliminary by design, and the authoritative sources arrive months later. Knowing precisely which is which is most of the discipline.
What you actually have on day one
Two things, essentially.
The first is the Storm Prediction Center's daily storm reports. These are drawn from NWS Local Storm Reports, usually sent in near real time, and they are grouped by a 1200 UTC to 1159 UTC day rather than by a local calendar day. That offset catches people out, because an overnight event can land on either side of it. Today's page is updated every ten minutes, starting at 6 AM CST or 7 AM CDT, a separate page covers the last three hours, and yesterday's reports cover 6 AM to 6 AM local time. Archived reports can be retrieved by date, and KML files and a REST service are offered.
SPC is clear about what those reports are. It labels them preliminary and shows them as is, and the reports page itself carries the notice "All Reports Are Considered Preliminary." For post-storm summaries, SPC points users to NWS Storm Data by way of the NCEI Storm Events database, which is the part that has not happened yet.
It helps to know who assembles that stream. Local NWS offices collect the information from sources such as damage surveys, emergency managers and SKYWARN spotters. That is a human pipeline, and it fills in unevenly across the hours and days after an event.
The second thing you have is active alerts. The public NWS API at api.weather.gov is free, needs no API key, and requires every request to carry a User-Agent header identifying the application (service documentation). It is useful, and it is not an archive. The documentation states the API does not provide a long-term archive, and that alerts from the alerts endpoint cover only the past seven days, with NCEI hosting the official archive of NWS alerts.
That clock is shorter than a slow sales cycle. If you want the alert text for an event you are still arguing about in a month, you had to capture it when it was live.
What will not exist for three to four months
The authoritative record is not late by accident. It is a different product with a different pipeline.
Both the Storm Data publication and the reports in the Storm Events Database are available 90 to 120 days after the event. During the entire period in which you canvass, sell, scope, submit and argue a storm, the record that everyone will later treat as official does not exist.
Certified official copies have a separate path: they must be requested from NCEI, not from local NWS offices. And where an event is missing from both sources, the NWS position is blunt: "it was not reported to the National Weather Service." Not reported is not the same thing as did not happen, which is the reason the second trap below exists at all.
The archive's coverage is worth knowing for when you eventually get there. The Storm Events Database covers tornadoes since 1950, severe thunderstorms since 1955, and all other weather events since 1996. SPC's own severe weather database, compiled from NWS Storm Data, runs hail and damaging wind reports back to 1955 and tornado reports back to 1950, and SPC states that the current year's reports are preliminary. One detail in those files bites anyone comparing across years: the NWS raised the severe hail threshold from 0.75 inch to 1.00 inch in 2010, and 0.75 inch reports remain in the annual hail files for legacy purposes, so users may need to filter them out.
The first trap: deciding on a record that is going to change
Here is the uncomfortable structure of the first 72 hours. You have to commit crews, book inspections and set expectations with homeowners using a dataset that is labeled preliminary, and the version other people will later call authoritative shows up after the job is finished.
There is no way to make that go away. There is a way to stop it from hurting you, and it is clerical rather than clever: record what you pulled and when you pulled it. A screenshot in a group chat is weak. A saved copy of the response, with the source, the query and the timestamp, is strong, because it answers the only question anyone asks later, which is why you believed what you believed on the day.
The opposite habit quietly destroys your own audit trail. Re-pulling the same source months later and assuming it says what it said before leaves you with no evidence of the earlier state. Preliminary reports get corrected, consolidated and sometimes removed. That is the system working as designed, and it is why the pull needs a timestamp.
The second trap: the thin part of the map is not the quiet part
The second trap is harder to see, because the map looks like information.
Severe weather reports cluster around population centers. SPC says so about its own database, and adds that wind reports are mostly verified by falling trees rather than by measured gusts, so they tend to cluster where trees are more common. The same page notes the data are used for NWS warning verification and may not capture all storm events, and describes the monetary loss figures in the database as highly suspect.
Put that alongside a fresh event map and the obvious conclusion flips. An area with few reports is an area with few reporters. On the morning after a storm, the thin part of the map is frequently the part nobody has driven yet, while the dense part is frequently the subdivision where a spotter happens to live. Reading report density as damage density gets the routing backward.
That last step is reasoning, not a finding, and it should be labeled as such. What the sources establish is the reporting bias. What follows for your route is a judgment: the quiet edge of a fresh map deserves a drive before it deserves a conclusion.
What the forecast side gave you before the storm
The counterweight to all of this is that the forecast side is fast, and the staging decision gets made before the event rather than after it.
SPC issues convective outlooks for Days 1 through 3, plus a Day 4 to 8 outlook covering roughly 72 to 192 hours out. That is the range in which a company decides whether to have people within driving distance at all, and it is the product that does the most work for a storm business.
Closer in, mesoscale discussions address severe potential over the next 6 hours with emphasis on the first 1 to 3 hours, and SPC aims to issue them 1 to 2 hours before a watch. Watches typically last 6 to 8 hours, and a watch is not a warning. SPC's stated lead-time goal is at least 45 minutes for the first severe thunderstorm watch of the day, and average lead time is about 1 hour for severe thunderstorm watches and about 2 hours for tornado watches.
About an hour is the real window in which staging decisions get made, and it is worth being honest that an hour does not move a crew across a state. What it is long enough for is to hold a crew that is already positioned, or to stop one from standing down. That asymmetry is the argument for paying attention to the Day 1 through 3 outlooks rather than waiting for the watch.
Three habits
Everything above reduces to three habits, none of which cost anything.
Pull with a timestamp and keep what you pulled. The preliminary record is the only record you will have while the job is live, and the saved copy is what makes an early decision defensible once the record changes underneath you.
Work a geometry instead of a city name. A place name is not a footprint, and the report points visible on day one are a sample of observers as much as a sample of hail.
Plan on revision. Assume the official version of the event will differ from the one in front of you, build the three to four month gap into how you talk to homeowners and adjusters, and never quote a preliminary report as though it were the archive.