EDM monitors: useful, imperfect, and sometimes a bit theatrical.

I once stood in Pateley Bridge staring at a storm overflow on a spill map, watching a site that was supposedly discharging. The map looked confident. The site looked silent. The river, as far as I could tell, was innocent.

That is the strange beauty of Event Duration Monitoring. It has changed the way the public can track storm overflow activity — giving far more visibility than was possible before — but it is still a system built on sensors, telemetry, and the occasional prayer to the gods of underground communications. Sometimes it misses things. Sometimes it reports things that didn't happen. Understanding the difference is part of reading this data well.

EDM is one of the most important transparency tools in the water industry. It is also not a truth machine. Both of these things can be true at the same time.

What EDM actually does

EDM monitors are fitted to storm overflows and record when a site is operating and for how long. The data is used for near-real-time public reporting (which is what WaterWatch reads) and also feeds into annual reporting to regulators. Before EDM was mandated at scale, much of this information simply wasn't available — you either had spot checks, or nothing.

The Environment Agency, CIWEM, and UKWIR have all described the same basic reality about this system: EDM works in messy underground conditions, relies on telemetry links that can be interrupted, and requires validation, interpretation, and maintenance to stay useful. The data is essential. It is not effortless.

The two failure modes

There are two ways EDM data can mislead, and they pull in opposite directions. One makes a site look better than it is. The other makes it look worse.

When monitors don't report (underreporting)

The first failure mode is the quiet one. A monitor can go offline, lose its telemetry signal, suffer a device failure, or simply stop recording properly. If that happens during a real spill event, that discharge may not appear in the record at all. The data shows nothing. The river tells a different story.

This kind of error tends to flatter a site unfairly. A gap where a spill should have been recorded makes the site's history look cleaner than it actually is. It is also harder to spot from the outside, because the absence of data looks the same as the absence of activity.

This is why WaterWatch tracks monitor uptime separately from discharge activity. A monitor with gaps in its record is not the same as a monitor that recorded no spills. The difference matters.

When monitors overreport

The second failure mode is the more visible one — and the one that turned Pateley Bridge into a minor personal philosophy. A sensor can trigger from silt in the chamber, debris passing through, calibration drift, a blocked float switch, or comms noise between the site and the telemetry system. The monitor says "spill." The river says nothing in particular happened.

CIWEM's good-practice guidance is clear that different sensor designs all have their own failure modes, and water companies openly acknowledge that false readings have to be removed through validation processes. Yorkshire Water, for example, describes ongoing work to identify and remove false alerts from its monitoring data, and flags issues like negative or flatlining readings as signals that something is wrong with the sensor, not the sewer.

Not every spike is a scandal. Not every glowing pin is a full confession. The data is incredibly useful, but it needs context, validation, and the occasional raised eyebrow.

What happens to historic data

This is the part I want to be careful and honest about: I do not fully know the exact historic correction process each water company follows when a monitor is later found to have been overreporting. What I do know is that companies are required to validate their data, that the Environment Agency's Storm Overflow Assessment Framework has specific rules about how to treat incomplete or unreliable monitoring records, and that the better companies investigate and revise where the evidence supports it.

The public-facing explanation of this process is often thinner than the technical reality behind it. That is not unique to water companies — it is probably true of most infrastructure systems if you look closely enough. But it does mean that a spill record should be read as a signal, not a court transcript.

When monitors go offline during site works

The upgrade scenario deserves more attention than it usually gets, because it is the one where a data gap is most easily misread in either direction.

Take a common upgrade type: installing a new storm tank alongside an existing CSO chamber. The tank is excavated and the overflow structure is opened up. While the civil works are live, the EDM float switch — which normally bobs in the overflow chamber to detect discharge — may be suspended above an open void, or temporarily removed for access. There is still physical space for wastewater to flow. But the sensor cannot run cleanly, or is disconnected entirely. The site might be half-built and still processing flow. The record shows nothing either way.

Or consider pipe relaying. When the upstream inlet pipe to a chamber is dug up and relaid, the chamber is effectively offline as a functioning overflow — but any EDM data gap from that period looks identical to a routine comms outage. Or groundworks near a site can cut the power or data cable to the telemetry cabinet on the fence line: the sensor is fine, the chamber is fine, but nothing is being transmitted.

None of these are signs of environmental failure. None are signs that the overflow performed perfectly either. They are engineering realities, and the honest thing to say is that context matters enormously here. A gap in data during a construction period should be read as "we don't know" — not as silence or innocence.

This is why any analysis that crosses an upgrade window — like the Witney STW analysis — excludes a window either side of the construction period from both comparison windows. It is not a perfect fix. But it is a deliberate attempt to stop the noise of an upgrade from distorting the signal of the data.

What this means for reading WaterWatch

WaterWatch reads EDM data in near real-time, exactly as it is published. We do not second-guess individual readings in the live feed — if the monitor says a site is discharging, we show it as discharging. If it goes offline, we mark it as offline.

For historical analysis — the kind that goes into site improvement assessments, trend charts, and annual summaries — the EDM limitations above are part of the reason we add confidence ratings, use longer windows rather than short snapshots, and say plainly when data quality is uncertain. The numbers are real. The caveats are real too.

The goal is not to make EDM data look perfect. It is to help you read it accurately — knowing when to trust it, when to ask questions, and when to read the absence of data as a data point in its own right.