Six readings that keep the field CLEAR

Storm cell tracking is the foundation of everything else we do. We identify convective cells the moment they appear in the fused radar and satellite picture, then follow each one through its life cycle. The tracker maintains a motion vector, a size estimate and a confidence value, all of which update continuously rather than at fixed intervals. For an operator this means the map they are watching is never more than a moment out of date.

The value of tracking lies in timing. A cell that will cross a work site in forty minutes is a scheduling problem, while the same cell in ten minutes is an emergency. By publishing an arrival window alongside the track, the tracker lets a dispatcher decide which of those two situations applies before committing a crew. We also record every forecast track so that performance can be reviewed after the event, which is how the system keeps improving season over season.

Tracking output is available as a live display, as a structured record through our data API, and as the input to alert delivery. It is the reading that most other services build on, which is why it is usually the first thing we deploy for a new client.

Lightning is the most immediate signal that a storm has become electrically active, and it is often the earliest warning that a cell is intensifying. Our lightning network combines ground detections with total lightning data from a fused sensor set. Every detection is geolocated, time aligned and quality checked before it enters the observatory feed.

Clients who take the feed receive a stream rather than a chart. Strike records carry a location, a time and a classification, and are delivered in a schema designed for machines first. This makes the feed suitable for automated systems that need to trigger an action the instant the strike rate jumps, without waiting for a human to interpret a picture. We monitor the health of the network continuously and flag any degradation so that downstream logic can respond appropriately.

Sudden changes in strike density are especially useful when read together with storm cell tracking. A cell that begins producing frequent lightning is very often the same cell that will soon produce hail, which is why the two services are designed to be used side by side.

Hail leaves evidence, and our job is to capture it before the evidence disappears. Field pads and observer reports are logged with a time stamp, a location and a stone size estimate, then mapped against the storm track that produced them. The result is a durable record of what fell where, useful long after the sky has cleared.

For growers, roofers and claims teams, this record is frequently more valuable than the original warning. It allows an event to be reconstructed with confidence, supports comparisons across a season, and reduces the guesswork that surrounds damage assessment. We treat every reported stone as an observation to be measured rather than an anecdote to be repeated, and we keep the source of each report attached to the record.

Hail reporting also feeds back into the forecasting side of the observatory. When measured stones arrive from a tracked cell, that outcome is compared with what the model expected, and the comparison is used to sharpen future hail estimates.

A crew does not need every chart in the observatory. A crew needs to know where the convective risk sits along the intended route, how it is likely to move, and whether the window for departure is closing. Our aviation weather briefings are written to answer exactly those questions in plain language, backed by the tracked cell picture and the lightning feed.

Each briefing highlights convective threats in the order a flight will encounter them, notes significant hail or lightning activity, and states the confidence behind the guidance. We deliberately avoid dressing up uncertainty as certainty. If the situation is ambiguous, the briefing says so, because a pilot who understands the limits of a forecast can plan around them far better than one who is handed false confidence.

Briefings are issued for the routes and time windows our clients fly, and they are refreshed as conditions change. They are designed to be read quickly in the minutes before departure, not studied at length after the decision has already been made.

Many organisations already have the systems that will consume our data. What they lack is a reliable way to get the observatory readings inside those systems. Data API integration is the service that closes that gap. We expose tracked cells, lightning detections, hail records and briefing summaries through a documented interface with stable schemas, sensible rate limits and clear authentication.

Crucially, we do not simply hand over a key and wish you luck. Integration is scoped with you, tested against your environment and documented for your team. This is the integrated systems design discipline at its most practical, and it is where clients often discover that our value comes as much from understanding their operational constraints as from understanding the atmosphere.

The API is versioned so that changes arrive without breaking working code, and every field carries enough context to be interpreted correctly by an engineer who did not build the observatory. When something upstream changes, the integration is updated deliberately rather than silently.

Alert delivery is the last mile, and it is where most weather systems quietly fail. A warning that never reaches its audience has no value, no matter how accurate the underlying forecast. We configure delivery across the channels that actually reach your people, whether that is email, messaging, a dashboard notification or an automated action inside your own systems.

Just as important as the channel is the threshold. An alert that fires too often is ignored, and an alert that fires too rarely is dangerous. We work with you to tune thresholds to your risk tolerance, then test the whole path until it behaves predictably. Testing is not an afterthought here. We treat the delivery path as a system in its own right, with its own failure modes and its own monitoring.

The outcome of a good setup is an alert that arrives early, says something genuinely useful and is trusted by the people who receive it. That trust is built through honest thresholds and consistent performance, not through louder notifications.