The number that decides your claim
If your contract is NEC4, a specific number sits at the heart of every weather compensation event claim: once in ten years. The weather conditions must have occurred — statistically — less frequently than once in any ten-year period at the project location. If the weather was unusual but not that unusual, there is no compensation event. If it was that unusual, there is — but only if you can prove it.
Under AS 4000 and NZS 3910, the wording is different but the logic is the same. The benchmark is what a competent contractor could reasonably have anticipated. Weather that falls within historical norms was anticipatable. Weather that exceeds historical norms was not.
Under JCT contracts, the threshold is "exceptionally adverse weather conditions." There is no formula. But you still need historical data to establish what counts as exceptional at that specific location.
In every case, winning a weather EOT requires a benchmark. You cannot prove the weather was unusually bad without a reference point for what is usual.
What a percentile actually means
A percentile tells you where a measurement sits within a distribution of historical values. The 90th percentile for monthly rainfall in a given location is the rainfall total that is exceeded in only 10% of months — i.e., roughly once every ten months, or about once per year.
The once-in-ten-years threshold used in NEC4 is equivalent to the 90th percentile of annual data — but when applied month by month (which is how most construction programmes are structured), it refers to the 90th percentile of each individual month across ten or more years of historical records.
This is why the benchmark must be calculated for the specific project location and the specific calendar months of the contract programme — not regional averages, not nearby airports, not national statistics. The benchmark is always site-specific and always time-of-year-specific.
How NEC4 uses the once-in-ten-years threshold
NEC4 Option X2 sets out the weather compensation event mechanism. Weather data is measured at defined intervals (typically daily) and compared against an established weather data schedule, which records the 10-year return period values for the project location. A compensation event arises when cumulative measured weather data for any calendar month exceeds the value recorded in the weather data schedule.
In practice, this means:
- The weather data schedule must be prepared at tender stage and included in the contract documents.
- The schedule records the 10-year return period values — the 90th percentile — for each weather parameter (rainfall, temperature, wind) and each calendar month.
- During the works, weather is measured at an agreed reference point — often a nearby weather station or one specified in the contract.
- At the end of each month, the measured data is totalled and compared to the schedule. If the measured total exceeds the 90th percentile value for that month, a compensation event has occurred for the excess days.
This means that how the weather data schedule is constructed matters enormously. A contractor tendering on an NEC4 contract should understand the historical weather profile at the project location before pricing — and certainly before the weather data schedule is agreed.
How AS 4000 and NZS 3910 approach the benchmark
Neither AS 4000 nor NZS 3910 use the explicit statistical mechanism of NEC4 Option X2. Instead, both apply a test of reasonable anticipation — what a competent contractor could or should have anticipated at the time of tender.
AS 4000 (and its predecessors AS 2124 and AS 4902) provides for delay relief where weather conditions arise that a competent contractor could not reasonably have anticipated at the time of tendering. The test is not automatic: the contractor must demonstrate both that the conditions occurred and that a competent contractor would not have allowed for them in the programme.
NZS 3910 similarly references conditions that could not reasonably have been anticipated, often read alongside the historical profile for the project location. In practice, New Zealand tribunals and engineers have applied a statistical reading consistent with a 10-year or 20-year return period as the threshold for "reasonably anticipatable" conditions.
In both jurisdictions, the key question is: would a reasonable contractor have allowed for this weather? Historical data provides the answer. If the weather was within the 90th percentile range for that location and time of year, the answer is likely yes — it was foreseeable, and no extension is due. If it exceeded that range, the argument for an extension becomes much stronger.
How JCT defines 'exceptionally adverse weather conditions'
JCT contracts (including JCT Design and Build and JCT Standard Building Contract) provide for Relevant Events that entitle the contractor to an Extension of Time. Exceptionally adverse weather conditions is one of those Relevant Events.
JCT does not define "exceptionally adverse" numerically. There is no built-in statistical threshold. This places more weight on the contractor's ability to demonstrate, through historical data, that the weather conditions were genuinely exceptional relative to what would be expected at that location during that time of year.
In English law, this has been interpreted consistently as weather that is more severe than could reasonably have been anticipated — an outcome not meaningfully different from the AS 4000 and NZS 3910 tests, even if the mechanism for proving it differs slightly.
The practical approach for JCT is identical to the others: gather historical data for the project location, calculate the 90th percentile for each relevant calendar month, and demonstrate that the actual measured conditions exceeded that benchmark.
What parameters are benchmarked
Weather contracts typically consider multiple weather parameters, not just rainfall. The parameters that affect construction work vary by trade operation:
Volume and frequency
Total monthly rainfall is the most commonly benchmarked parameter. Some contracts also specify minimum thresholds per event (e.g. more than 1 mm in a 24-hour period) to exclude negligible rain events from the count.
Mean speed and gusts
Wind speed (mean) and gust speed are benchmarked separately. Gust exceedances are particularly important for crane operations, roofing, scaffolding and cladding — where instantaneous peaks are the operative threshold, not sustained averages.
Minimum and maximum
Minimum daily temperature affects concrete pours, coatings and structural adhesives. Maximum temperature affects productivity and safety. Both can be benchmarked independently for the relevant trades.
Snowfall, humidity, frost
Some contracts and jurisdictions also benchmark snowfall days, ground frost days or high-humidity periods — particularly relevant to earthworks, paving and external coatings in colder climates.
The parameters that matter for a specific claim depend on both the contract wording and the affected trade operations. A concrete pour delayed by cold temperatures requires a temperature benchmark. A crane hold-down caused by gusts requires a wind benchmark. The benchmark must match the claim.
How the benchmark calculation works in practice
The calculation process has three steps. Each step matters — getting one wrong can invalidate the benchmark, and therefore the claim.
Step 1: Gather the historical dataset
A minimum of ten years of historical weather data is required for the specific project location, or the closest appropriate reference point. The NEC4 option X2 mechanism explicitly references a 10-year dataset. For AS 4000 and JCT purposes, ten years is the accepted minimum for statistical credibility.
The data must be sourced from a legitimate meteorological record — typically a national weather service, an international reanalysis dataset (such as ERA5), or an agreed project weather station. Data from consumer weather apps, personal weather stations or informal sources is rarely acceptable in a formal claim context.
Step 2: Calculate the monthly 90th percentile
For each calendar month and each weather parameter, the historical values are ranked from lowest to highest. The 90th percentile is the value at the 90th position in a 100-value distribution, or equivalently the 9th value in a 10-year ranked dataset for that month.
For example: if the October rainfall totals across ten years were (in ascending order) 42 mm, 51 mm, 58 mm, 63 mm, 71 mm, 79 mm, 84 mm, 93 mm, 107 mm and 134 mm — the 90th percentile is 107 mm. In nine out of ten years, October rainfall was below 107 mm. In one out of ten years, it exceeded it.
Step 3: Compare measured conditions to the benchmark
During the works, actual measured weather data is recorded for each day and month. At the end of each contract month, the measured total is compared to the 90th percentile value from the benchmark table. If the measured value exceeds the benchmark:
- Under NEC4: a compensation event arises for the excess days beyond the allowance.
- Under AS 4000 / NZS 3910: the conditions exceeded what could reasonably have been anticipated, supporting an EOT claim for the affected period.
- Under JCT: the conditions were "exceptionally adverse" relative to historical norms, supporting a Relevant Event claim.
Common mistakes that undermine the benchmark
The benchmark is only as credible as the method used to produce it. These are the most common errors that weaken or invalidate a weather benchmarking analysis:
- Using the wrong location. Regional or national averages are not the same as site-specific data. A weather station 30 km away at a different elevation can produce materially different figures. The benchmark must reflect conditions at the project location.
- Using too short a dataset. Five years of data is insufficient for a statistically credible 90th percentile. Ten years is the minimum; more is better. A five-year dataset will overstate or understate the percentile depending on whether those years happened to be wet or dry.
- Benchmarking the wrong parameter. A trade delayed by wind gusts cannot be supported by a rainfall benchmark. The parameter must match the actual cause of delay.
- Mixing measured and estimated data. If some months use measured station data and others use gridded model estimates, the dataset must be consistent. Mixed sources can introduce systematic bias.
- Not accounting for the allowance already in the contract. Under NEC4 Option X2, the compensation event is for weather in excess of the allowance in the weather data schedule — not for the whole of the adverse month. If the schedule already builds in a 10-year return period, the contractor gets relief only for the days beyond that level.
How Construction Weather produces the benchmark
Construction Weather's EOT Evidence tool calculates the historical benchmark automatically for any project location, using ten years of high-resolution reanalysis weather data. The process removes the most common sources of error:
Site-specific data
The historical dataset is drawn from a gridded reanalysis source calibrated to the project's latitude and longitude — not the nearest weather station, which may be distant or at a different elevation. This produces a benchmark that reflects the actual site environment rather than a proxy location.
Consistent methodology
The same methodology is applied consistently across all months and parameters: ten years of data, the same percentile calculation, the same parameter definitions. The method is disclosed so that project teams, engineers and administrators can verify the approach.
Contract clause integration
The contractor can supply the actual weather clauses from the contract — the specific wording of the NEC4 weather data schedule, the AS 4000 delay clause, or the JCT Relevant Event definition. The analysis is then structured around that specific wording, so the output directly answers the contract's question rather than a generic benchmark.
Formatted output
The result is a formatted document showing the monthly benchmark values, the measured conditions for each project month, and a comparison identifying which months exceeded the 10-year return period threshold and by how much. This can be exported and included directly in an EOT submission as supporting evidence.
Why the benchmark matters at tender stage too
The 10-year return period benchmark is not only a claim tool. It is also the foundation of an accurate tender allowance.
A contractor pricing an NEC4 contract should understand the historical weather profile for the project location before agreeing the weather data schedule. If the schedule underestimates the 90th percentile values — perhaps because it uses regional averages rather than site-specific data — the contractor will carry more weather risk than the contract mechanism was designed to allocate. If the schedule overestimates, the contractor may be carrying a larger allowance than the statistics justify.
Either way, understanding the benchmark before the contract is signed protects the contractor's position during both tender and delivery. See the guide to pricing weather risk at tender stage for the full detail on how historical data informs tender allowances by trade and month.
Frequently asked questions
What does 'once in ten years' mean in NEC4 weather claims?
Under NEC4, clause 60.1(13) provides for a weather compensation event when the weather measurement recorded in the Contract Data is exceeded during a calendar month. The Contract Data records the 10-year return period values — the 90th percentile of historical data — for the project location and each parameter. This means the threshold is the level that would be exceeded in only one out of ten years historically. If the weather was unusual but not that unusual, there is no compensation event.
What is the 90th percentile in weather benchmarking for construction?
The 90th percentile is the value exceeded in only 10% of historical records for the same calendar month and location. For example, if you rank October rainfall totals across ten years from lowest to highest, the 90th percentile is the 9th value in that ranked list — the second-highest overall. In nine out of ten years, October rainfall was below that figure. In one out of ten years, it exceeded it. This is the statistical threshold used to define 'once in ten years' weather under NEC4 clause 60.1(13).
How is the weather benchmark calculated for an EOT claim?
The benchmark calculation has three steps: (1) Gather at least ten years of historical weather data for the specific project location from a legitimate meteorological source. (2) For each calendar month and weather parameter, rank the historical values and identify the 90th percentile — the second-highest value in a 10-year ranked dataset (the value exceeded in only one out of ten years). (3) During the works, compare the measured monthly totals to the benchmark values. Where measured conditions exceed the 90th percentile, a compensation event or EOT entitlement arises depending on the contract form.
What weather parameters are benchmarked in construction contracts?
Construction contracts typically benchmark multiple parameters: rainfall (total monthly volume and sometimes event frequency), wind speed (both mean speed and gusts — gust exceedances matter most for crane operations, roofing and scaffolding), minimum and maximum daily temperature (affecting concrete, coatings and productivity), and in some contracts snowfall days, ground frost days or high-humidity periods. The parameters that matter for a specific claim depend on the contract wording and the affected trade operations — the benchmark must match the actual cause of delay.
How does JCT define 'exceptionally adverse weather conditions'?
JCT contracts list 'exceptionally adverse weather conditions' as a Relevant Event entitling the contractor to an Extension of Time, but JCT does not define 'exceptionally adverse' numerically. There is no built-in statistical threshold. In practice, English law has interpreted it consistently as weather more severe than could reasonably have been anticipated — which requires historical data for the project location. The practical approach is identical to NEC4 and AS 4000: calculate the 90th percentile benchmark for each relevant calendar month and demonstrate that actual measured conditions exceeded it.
What are the most common mistakes that undermine a weather benchmarking analysis?
The most common errors are: using regional or national averages instead of site-specific data (a station 30 km away at a different elevation can produce materially different figures); using too short a dataset (five years is insufficient — ten years is the accepted minimum); benchmarking the wrong parameter (a wind-gust delay cannot be supported by a rainfall benchmark); mixing measured station data with gridded model estimates without consistent treatment; and failing to account for the allowance already in the contract — under NEC4 clause 60.1(13), the compensation event covers only weather in excess of the weather measurements recorded in the Contract Data, not the whole of the adverse month.
The benchmark turns a weather complaint into a contract argument
The once-in-ten-years threshold — and the 90th percentile calculation that underpins it — is the mechanism that separates a contractually valid weather EOT from a site complaint. Without the benchmark, a contractor can only argue that the weather was bad. With it, the contractor can demonstrate that the weather was statistically unusual at this location, during this period, relative to a defined historical record.
That shift — from subjective complaint to objective analysis — is what makes a weather claim credible. The contract asks a specific question. The benchmark provides a specific answer.
Construction Weather calculates that benchmark automatically, for any project location, across ten years of historical data, with outputs structured around your contract's specific wording. The analysis that used to require a meteorological expert can now be part of the standard claim package.