Thames Water fault tracker

What this is

Thames Water publishes a map of current problems — leaks, blockages, flooding, pollution — but it only ever shows now. A fault that has been open for two years looks exactly like one raised this morning, and once a pin disappears there is no record it was ever there.

This site snapshots that map every hour and keeps the history. That makes it possible to ask the questions the map cannot answer: is the backlog growing? How long does a leak actually take to fix? How many faults have been open for over a year? Which areas wait longest?

Where the data comes from

The map is an ArcGIS application, and its feature layers are public. Five are read directly and unchanged. Nothing here is estimated or modelled: every number is a count of Thames Water's own published records.

• Open work orders — CleanWaterOpenWorkOrder and WasteWaterOpenWorkOrder. Work Thames Water has scheduled and not yet finished.
• Closed work orders — CleanWaterClosedWorkOrder and WasteWaterClosedWorkOrder. Work they have finished with, marked Completed, Canceled or Repair Complete — the third of which does not mean what it sounds like, as below.
• Public reports — the pending-pins layer behind the “Leak” markers. What appears the moment somebody reports a problem, before any work order exists.

A sixth source, on a different clock, is the Department for Transport's Street Manager open data: the statutory register of permits to dig up a road in England. Thames Water must apply to the highway authority before opening a road, stating when the work will start and finish. Those applications, and the dates the work actually started and finished, are published monthly in arrears. That is what “Their own permits, their own deadlines” on the overview is built from — a deadline Thames Water set for itself, compared against its own record of meeting it. Permits are matched on the promoter name, and only Thames Water's records are kept.

Reports and work orders are counted separately, because they are different things: a report is a member of the public saying something is wrong, a work order is Thames Water scheduling work. Thames Water keeps only about a week of reports, so one that never becomes a work order vanishes from their map with nothing to show it was ever made. Those are kept here.

How to read it

Ages and outcomes

• Age is measured from WorkOrderRaisedDate, Thames Water's own timestamp for when the work order was created.
• Cleared means a fault stopped appearing in the open feed. Where that fault also turns up in the closed feed, Thames Water's own verdict is shown — Completed or Canceled. Where it does not, we genuinely do not know what happened, and the site says so rather than assuming a repair.
• “Repair Complete” is not counted as a repair. It is a third closed-feed status, and it is not an outcome: 79.8% of the records carrying it still have outstanding line items on them, against 2.8% of those marked Completed. Of 947 times we have watched a work order move into it, 688 saw its count of open line items go up at that moment, not down. It is treated here as an absence of a verdict, and where a fault's status contradicts its own line-item count the Faults tab marks it.
• The completion timestamp on those records moves. Of 1,093 work orders that have had a repair_complete_at set, 751 had it revised afterwards, across 2,001 revisions — every one of which pushed it later, none earlier. It appears to follow the most recently finished task on a job rather than the finishing of the job, which restarts the 72-hour countdown that removes the pin. So a record can show a finished status for ten days while the date beside it never reads older than three. Where the two disagree, this site counts from the status we watched change, not from the timestamp.
• Time to clear is estimated, not averaged. Taking the median across the faults that have cleared sounds reasonable and is not: a fault can only appear in that average once it has finished, so the faults still open — the slow ones — are silently left out, and the answer comes back shorter than the truth. The “How long until a fault clears?” panel instead follows every fault raised since collection began and counts the ones still open as unfinished (a Kaplan-Meier estimate). On the current data the estimate is about a third longer than the plain average of those that finished.
• That cohort is defined on the date Thames Water raised the work order, not the date we first saw it. A fault can appear on the map long after it was raised — one cleared 966 days after its raised date — and including those would put back exactly the bias the estimate exists to remove, since we never saw their early life.
• The curve stops where the data does. Nothing can be said about times longer than the oldest fault in the cohort, so it is not drawn, and the number of faults still under observation is published beside every figure. Both the reach and the precision improve with every day of collection.
• The second, longer curve is a different kind of estimate. It uses every fault rather than only those watched from the start, by letting each join the calculation at the age it was when we first saw it. That reaches months instead of days, but each fault still contributes only a fortnight of watching — so the rate at four months comes from faults that happen to be about four months old now. It answers “if this fortnight’s rates held at every age, how long would a fault raised today take?”, and nothing in it has been watched for four months. Where the two curves overlap they agree, which is the main reason to trust either.
• About two thirds of the faults that have left the map went in bulk removals the closed feed never confirmed. Those count as “stopped watching” rather than “fixed” in both estimates. That is the honest handling, but it assumes they would otherwise have behaved like the records that stayed — if they were in fact quietly completed work, both curves overstate how long faults take.
• “Cleared” means off the map, which is later than fixed. Thames Water keeps a finished record published for a further 24 or 72 hours depending on the job, and that shows up as a hard floor in the times — almost nothing disappears within a day. The repair finished earlier than these figures show, by up to that period. It is not subtracted, because the retention clock runs from a completion timestamp that is itself revised forward on most records.
• A minority of closed records carry a real closure date; most do not.
• Faults sometimes drop out and come back between collections. Those are counted once and flagged, not double-counted as new.
• Faults that have not started are counted against Thames Water's own published status. A fault is treated as under way once it reaches Repair Underway, Repair Complete or Completed; anything at Reported, Investigation or Repair Planning has not begun. Nothing is inferred — it is a count of statuses. Note this runs opposite to the obvious guess: faults that have reached a repair stage are younger than those that have not (median 20 days against 44), so a long-open fault is usually one waiting to start rather than one going wrong repeatedly.
• Most faults never publish a repair stage at all — about 95% of those that cleared went from Investigation straight to finished, consistently across every problem type, and most carry a single line item. So “never reached Repair Underway” is closer to the normal path than to a failure, which is why the panel reports where the backlog is waiting rather than counting repairs that never happened.
• Where the backlog is stuck counts open faults by lifecycle stage and how long since each last moved. It deliberately does not give an average time per stage: a stage visit can only be timed when both its start and end are seen, so with a short history that average would measure only the visits quick enough to fit inside it. It would have read “four hours in Investigation” while three quarters of the faults there had not moved in a week.
• The Faults tab switches between still open and cleared, and cleared faults can be filtered by when they went, down to the last hour. That is the way to see what a sudden movement in the backlog actually consisted of — and to check how much of it Thames Water's closed feed corroborates, which for a bulk departure is usually very little.
• A clearance time is the collection that first found the fault missing, not the moment it left. Collection is hourly, so a departure is placed within about an hour; it is not exact, and the site does not pretend otherwise.
• Each poll is checked for completeness, not plausibility: every layer's own row count is read before and after, and if it disagrees with what was retrieved the run records the counts and changes nothing. A drop is never rejected for being too large — “too big to be true” is not a test of the data, and refusing observations on those grounds would put our judgement ahead of the measurement.
• When an unusual share of records vanishes at once and Thames Water's closed feed confirms almost none of it, the collection is flagged. Those departures are recorded and browsable, but they are kept out of the time-to-clear figures and are not drawn as clearing, so a single source-side event cannot rewrite every median here. The number excluded is published with them.
• The overview charts default to a recent window, with the full history a click away. One collection on 5 August 2026 removed two thirds of the backlog, and a drop that size cannot share a vertical axis with ordinary week-to-week movement without making it invisible.
• Anything that would otherwise leave a figure here unexplained gets a dated entry under Notes, with the evidence behind it. That is the one part of this site that is written rather than counted: the change log can show that thousands of work orders stopped being published, but not what it meant.

Permits

• A permit is counted late when the work's recorded end falls on a later calendar day than the end date applied for. Whole days, London time: the commitment is to a day, not an instant, so work finishing at nine the next morning is a day late rather than “0.4 days over”.
• Where a permit was extended and the extension granted, the comparison uses the revised date. An extension that was applied for and approved is not an overrun.
• The late rate published here is a floor, and roughly how far short is shown on the overview rather than asserted here. A job still running when the last month of records closes cannot be counted, so recent months are missing their longest jobs — and the late rate rises with both how long the work took and its category. The table by starting month sets each month against a control of jobs finishing inside two days, which are counted the same way throughout; the earliest months run several percentage points above their own control, the most recent barely any. Every figure there is recomputed on each build, so it tracks the months actually held rather than going stale.
• A month whose own archive is missing is excluded from that table entirely rather than shown with a caveat. The only works visible from such a month are those that happened to finish in a later one, which selects precisely for the longest jobs — June 2026 shows 20.4% of its works running beyond ten days, against 1.5–5.3% everywhere else. That is not a small sample, it is the wrong sample.
• Permits are not linked to individual faults here, and the tables say nothing about any particular pin on the map. A distance-and-date join between the two was built and tested against a null model that shuffles which fault sits at which location; it reached at best about five times chance while covering only 1% of faults, meaning roughly one in five surviving matches was still coincidence. Thames Water digs where its pipes are and its faults are where its pipes are, so proximity alone carries much less information than it appears to. Separately, about 18% of permits carry no coordinates at all, and those are disproportionately the largest schemes — the ones that overrun most. Rather than publish a weak link, the join is left unpublished.
• The archive is published monthly, in arrears, so this lags the rest of the site by up to a month. Only months whose archive is intact are used: the June 2026 file is truncated where it was uploaded and is excluded.

Reports, and how they link to faults

• Where a report and a work order share a street and postcode within three days of each other, each links to the other. That is an association inferred from place and timing — the two feeds share no reference number. It matches at street level, not house number: Thames Water's address field is a single free-text line and a leak reported outside one house is routinely worked on under the address of its neighbour. Where more than one work order fits, all are shown rather than one being picked. Shuffling which address belongs to which report still reproduces about a third of these matches, because a busy street gets work regardless — so a single link is suggestive, not established. Three days is the window that maximises the links actually attributable to a report having been made; widening it to a week added 114 real matches and 394 coincidental ones.
• A report leaving the map does not prove it became a work order, and a report can convert while its pin stays on the map — which is why the same address sometimes shows twice on Thames Water's map.
• “Leak” is Thames Water's label for the whole pending-pins layer, not a classification of each report; the feed carries no per-report problem type. Of reports that match a work order raised soon after on the same street, about 92% are leak investigations, but a few become flooding, blockage or pollution work.

Places

• Areas are ranked by open faults per 10,000 households, using ONS Census 2021 household counts, because a raw count mostly ranks population.
• A low rate is not evidence of good performance. Thames Water supplies only part of some local authorities, so faults are counted for their area while households are counted for all of it. Normalising by households also does not adjust for network age, pipe material or ground conditions.

Quirks of the source data

• Their map shows the case number; a fault also has a separate work order number. Both are searchable here.
• A small number of records — about 1.4% of reports and 0.2% of work orders — are published with no address at all: the source leaves street, town and postcode empty. They still carry coordinates, so those are shown instead. Address-less reports cannot be matched to a work order at all, which is one reason the report-to-fault links above are a floor and not a conversion rate.
• Work order times are published as UK local time labelled as UTC, which puts them an hour out during British Summer Time. That is corrected on collection, so times here are genuinely UTC.

Check the numbers yourself

Every collection is committed to the repository as a compressed change log, and the SQLite database is rebuilt from those files on every run — so any figure on this page can be reproduced from the raw record. The caveats above are in the README too, alongside the ones that only matter if you are going to quote these numbers at someone.

Source and data on GitHub Download the SQLite database

Not affiliated with or endorsed by Thames Water Utilities Ltd. Source released under the AGPL-3.0-or-later. Map tiles © OpenStreetMap contributors.