How the figures are counted

Where the data comes from

The data is collected from public sources of air raid alert notifications. Each raw message is stored in its original form; "start" and "all clear" events are derived from it, and alert periods for a specific administrative unit under the KATOTTG register are derived, in turn, from pairs of those events.

Periods when the source was silent or had not yet started observing are marked separately on every page they concern, and are not included in the calculations — see below.

How much this can be trusted

This is not an alerting system. The site describes the past. Make decisions about your own safety from official alert signals, not from these charts.

The data can be inaccurate, and here is exactly where:

• The end of an alert. When the source states the all-clear time, we take it. When it does not, we only know the alert ended somewhere between two checks, and we record the last moment it was still visible. The margin of error here is up to half a minute — more, if the source itself happened to be unavailable right then.
• Parsing the text. Part of the archive is messages written for people, not for machines. The great majority read unambiguously, but not all of it: some names coincide between different places closely enough that telling them apart from the text alone is impossible, and such messages are not counted at all.
• Periods no one saw. An alert that began and ended entirely within a stretch when the source was silent does not exist for us — and will not surface later. Such stretches are named on every page they concern.
• Villages and settlements. Alerts are announced by rayon and hromada. A settlement's page shows its hromada's figures, because it has none of its own — this is not a separate measurement, just the same one seen up close.
• The source itself. It can run late, correct itself after the fact, or simply be wrong. We carry its data forward — we do not verify it.

Where we don't know something, the page says so. An empty value here is more honest than a plausible-looking one.

Time

All moments are stored in UTC, and shown and grouped by Kyiv time (Europe/Kyiv), accounting for the daylight-saving switch. This is critical for the distribution of alerts by hour of day: a fixed offset would shift night-time alerts into neighboring hours.

Alert inheritance and double counting

An alert can be announced at oblast, rayon, or hromada level. We take it that inheritance runs downward only: an oblast-level alert extends to every rayon and hromada inside that oblast.

So a hromada's "time under alert" is the union of its own alerts with those of its rayon and oblast. When an oblast-level and a rayon-level alert overlap, the shared minutes are counted once, not twice.

The flip side of this rule: a rayon-level alert does not mean the whole oblast is under alert. Because of this, an oblast where alerts are mostly announced at rayon level will show a smaller "own" time in the ranking than people on the ground actually feel. That is honest to the data, but the oblast ranking should be read with that in mind — for the detail, see the page for the specific rayon or hromada.

What the number means for an oblast or rayon

The source announces alerts by rayon and hromada, not by oblast. So an oblast has no alerts of its own, and all of its figures are counted from what happened inside it: the alerts of all its parts are taken, and overlapping intervals are merged into one episode.

The merging is the crux of it. If six rayons were under alert at once at 03:35, that is eight minutes of real time, not forty-eight. So durations are never added — union comes first, measurement after. On one evening in Kyiv oblast, nine rayon-level alerts with a combined "sum" of 113 minutes produced two episodes totaling 66 minutes.

Because of this, "alert episodes" is not the number of source messages or the number of rayon-level alerts, but the number of distinct stretches of time. And "alert time" means the alert was somewhere within the territory, not that the whole territory was under it. A "whole territory" figure is a different quantity, and it first requires establishing which parts the source even observes.

Duration

The average, median, and longest durations are counted from episodes that have already ended. An active alert has no duration yet, and counting its current age would drag the median down exactly when the page is looked at the most. An episode that crosses a period when the source was silent is also excluded: its recorded end is the moment the source came back, not the moment the alert actually ended.

When the source is silent

Sources sometimes go down, and knowing when matters more than it might seem: an alert opened just before an outage never gets an "all clear," and its recorded end becomes the moment the source came back. Such an alert can end up looking like several days in a row.

So we keep a separate record of when the source was actually responding, rather than relying on silence to mean calm. Where no such record exists, the outage shows in the archive itself: under normal operation the gaps between messages are short, so a long enough pause counts as missing data.

The rule for such periods is the same everywhere: they are named on every page whose figures they touch; alerts that ran through them are excluded from the duration figures, because their true duration is unknown; and shares of time are calculated against the time the source was actually working. An alert's end is never filled in by guesswork.

The hourly map and long periods

The "when exactly" map is drawn for shorter periods. Over a year it would be 365 rows of 24 cells — a picture like that shows nothing. Over long periods, the same pattern is shown instead by the hour-of-day distribution charts, and the day-by-day chart shows how it evolved over time.

Historical frequency is not a forecast

The "share of days with an alert at this hour" figure describes what has already happened. Alerts depend on the enemy's actions, not on any internal pattern in the series, so this is not a forecast and must never be a reason to ignore an alert signal.