How we verify

Evidence levels

Every timeline entry carries at least one numbered source, and the database refuses to publish one without. Each incident has one of three evidence levels:

• Confirmed (shown as Damaged or Being fixed): the cable’s owner, operator or consortium, or another authoritative party, has said there is a fault. Normally we link that statement itself. If we can only link a reliable outlet reporting it, the incident page says so, and the API marks it confirmationBasis: REPORTED until the statement itself is linked.
• Suspected (shown as Reported): at least two independent kinds of signal agree, for example a routing change plus a credible report, but nobody authoritative has confirmed it.
• Observed: network measurements look abnormal. We show these as measurements and never as a cable fault.

How we rate sources

Sources are rated authoritative, reliable or unverified. Only a cable’s owner, operator or consortium, or a party with direct knowledge of the system, can confirm a fault. ISPs, maritime authorities and established trade press can support details such as location, repair ships and impact. Ratings can differ by cable: an operator is authoritative for its own systems but only reliable for someone else’s. Each citation keeps the rating the source had when we linked it. The full list is on Data and sources.

How incidents are put together

Incidents are compiled from operator notices, ISP status pages, maritime notices and established trade press. Where automated monitoring is on, software only drafts suggestions. A person checks every draft against the original source before anything is published. Software never publishes on its own.

When a source gives only a distance (for example “about 615 km from the Singapore landing station”), we place an approximate marker along the published route and draw a wide radius around it. The incident page says when a location is placed this way.

Repair ships

Cable ships are shown where receivers on land last heard their radio broadcasts (AIS). A ship near a fault is not assumed to be repairing it: a ship is named as the repair ship only when a source says so. Ships far out at sea can go unheard for hours or days.

Network measurements

We measure routes between major cities with RIPE Atlas and use Cloudflare Radar’s outage reports. A route is flagged only when several probes on different networks show a sustained change: at least +15 ms and +20% over the measured baseline for 15 minutes or more.

The measured baseline is what the same probes measured at the same time of day on recent days. Days when a known incident was open on one of the route’s cables are left out, so a long outage never becomes the new normal; while one is open, the comparison is the measured pre-incident baseline, and the route page says so. A baseline describes those probes and their network paths, not the latency every connection should expect.

Some routes also show latency from our own server (SmokePing, every 5 minutes). It is one server on one network: context beside RIPE Atlas, never used to flag a route or judge a cable. Traffic can be rerouted for many reasons, so a slower route is never proof of a cable fault.

Conditions near a fault

Incident pages can show context from public feeds: earthquakes recorded near the fault around when it was reported, tropical cyclones near it, sea conditions there, and country-level internet outage signals. Official navigation warnings that mention cable work reach our editor as leads. None of these is ever given as a cause or as proof of a fault on its own; each is labelled and linked to where it came from.

History and corrections

Incident timelines are append-only. When an ETR changes, the old estimate stays visible. When we get something wrong, we add a correction entry instead of quietly editing the record.

Report a fault or a correction

Send a link to a public source with the report form on any cable or incident page, or by email. Reports go into a review queue, and nothing is published without a source we can check.