Cricket Australia’s heat policy takes eight steps, three documents, and time nobody has at the ground.

The workflow as written

Cricket Australia’s Community Cricket Playing in the Heat Guidelines (v4.0, September 2023) describe a compliance-grade heat check as the following sequence:

1. Open the Bureau of Meteorology website and locate the nearest weather station.
2. Read four data points: air temperature in shade, wind speed, relative humidity, sun exposure category.
3. Open the correct Excel file on play.cricket.com.au: one for adults, a different one for under-18s.
4. Enter the four data points manually.
5. Read the Heat Stress Risk Index value the spreadsheet returns.
6. Open the Cricket Australia policy document and look up what action that index value triggers.
7. Communicate the action to the umpires and the club representatives.
8. During any match running above HSRI 4, repeat the entire process hourly.

Three separate documents. Manual data entry. Field-side. On a Saturday morning. Across potentially hundreds of grade games happening simultaneously at any one time.

This is the published process. It is not the process anyone actually runs.

The workflow in practice

The Cricket Australia policy contains an explicit escape clause:

If the weather data is NOT available to calculate the HSRI, the Match Officials, Tournament Organisers and Club Representatives should make a common-sense decision about the likelihood of heat stress illness.

The clause was presumably intended for tablet failures and dropped network connections. In practice it has become the entire workflow at almost every ground. The data has never been unavailable. It has been impractical to retrieve, enter, and interpret in the time between setting up stumps and the first ball.

So the real workflow on a typical match day looks like this: look at the sky, feel the air, talk to the umpire, decide. Cricket isn’t unusual in this. A review of more than twenty Australian sporting organisations found the same pattern across the codes, and several community codes impose higher friction than cricket does.

What is unusual is what cricket’s policy doesn’t require: there is no obligation to log the check, retain records, or report outcomes. The compliance bar today is “did you think about it?”, not “did you measure it, and can you prove it?”

That gap is comfortable until something goes wrong.

Read the full argument: Why your heat policy probably can’t be followed →

What Cracking Flags does for a state cricket body

Cracking Flags collapses the published Cricket Australia workflow into a single screen. The user — an umpire, a duty officer, a community administrator, a coach — picks a ground, gets a live Heat Stress Risk Index value calculated from current weather conditions, and sees the organisation’s own policy response for that risk tier in the organisation’s own wording.

Specifically, for a state cricket administrator running a community competition, that means:

• One screen, one number, one action. The user opens Cracking Flags, picks the ground (saved, GPS, or address search), and sees the index value and the action the policy says to take. The four BOM data points, the right Excel file for the age group, and the policy table lookup all happen in the background.
• Your policy, not a generic one. Cracking Flags is algorithm-agnostic. It can run the Cricket Australia HSRI calculation, your association’s modified thresholds, or a third-party risk model, and it will surface your action wording at each tier. The umpire sees what your state body has decided to tell them, not what a generic tool decided to display.
• Every check logged automatically. Location, timestamp, weather inputs, calculated risk index, and the policy response that was returned, recorded against the organisation’s account for every check, every ground, every time. Queryable in the in-app analytics view and exportable to CSV.
• Manual override where judgement matters. The umpire who knows this ground feels hotter than the BOM reading suggests can adjust individual inputs and see the index recalibrate, with the adjustment recorded. The policy still runs; the deviation is defensible because it’s documented.

The administrator can configure thresholds and policy responses, upload and manage grounds, control user access, and browse historical data across the whole competition by ground, time, and result.

What this is not

Three things this page is deliberately not claiming, because honesty is the brand.

• This is not a medical tool. Cracking Flags surfaces environmental risk and the organisation’s policy response. It does not assess individual athlete risk, prescribe hydration, or replace medical judgement.
• This is not the Sports Medicine Australia heat policy tool. The SMA tool is good. It produces a credible category-of-day risk reading for healthy adults. It does not run your association’s specific thresholds, does not cover under-18s, and keeps no compliance record. Cracking Flags and the SMA tool answer different questions; they aren’t substitutes for each other. Read more on what the SMA tool does and doesn’t do →
• Some artefacts are not yet packaged. Pre-match email alerts and automated monthly compliance reports are roadmap, not live. The data underneath both is complete and queryable today; the artefact layer will be built in response to demand. We say so plainly.

What an incident inquiry actually asks

The strategic value of a compliance record only becomes obvious after the fact. When something goes wrong in Australian sport, the conversation that follows involves the insurer, the player or family, the player association, sometimes the media and the coroner. The question that gets asked is not “did you have a policy?”. Every organisation has a policy. The question is “did anyone check the conditions at this ground at this time, and what did the policy say to do?”

Today, across the community game in cricket, that question can’t be answered. The published workflow doesn’t require a record to be kept. The actual workflow doesn’t produce one.

With Cracking Flags, the question is a database query that returns an answer in seconds.