Why We Built Fiber Network Tracking Into an ISP Platform

Ask any ISP operator what their worst day looks like and the answer is almost always the same: a fiber cut. Dozens or hundreds of customers go offline at once, the phones light up, and a technician heads out with an OTDR to find the break — very often starting from zero, because nobody wrote down what that line looked like when it was healthy.

The Problem: Every Cut Starts From Zero

An OTDR (optical time-domain reflectometer) tells you how far along a fiber a fault is. That number is only useful with context: where is that distance on the ground, and what did a reading on the same line show last month when everything worked? In most operations that context lives in a technician's notebook, a phone gallery of device screenshots, or someone's memory.

So the same line breaks at the same spot under a market road twice in three months, and the second diagnosis takes as long as the first. We wanted the platform to remember.

Control Rooms and Fiber Lines

The module starts with a simple catalogue that mirrors how networks are actually built: control rooms (physical sites) and the fiber lines that leave them — the main trunk inputs. Each line has a start and an end point on the map and its staff-entered cable length.

Operators can view the whole network three ways: a list, a tree that shows each control room with its lines as branches, and a map where every control room gets its own colour and its lines branch out in that colour. A line with an open incident always turns red, so an active outage never blends into the background.

Baseline vs Diagnostic Readings

Every OTDR reading logged against a line is one of two kinds:

• Baseline — a routine, known-good reference trace taken while the line is healthy.
• Diagnostic — taken while actively chasing a cut, optionally tied to the incident it belongs to.

Each reading records distance, loss in dB, the device used and, optionally, a photo of the device screen or printout. Readings are an append-only log: they can be corrected, but never quietly deleted.

Cut Incidents With a Real Lifecycle

A fiber cut is logged as an incident that moves Open → Investigating → Resolved, with a full timeline of who changed what and when. A headline downtime counter runs while it's open, and resolution time is calculated automatically once it closes.

• Fault location — captured by GPS at the site, or picked on a map later when there was no clean signal at the break.
• Photos — several at once, from the field.
• Linked complaints — customer complaints caused by the outage are linked to the incident, and staff opening any of those complaints see a clear "part of a known outage" notice.

Seeing Recurring Faults on a Map

On each fiber line's page, a map view plots the control room and every incident with a captured location, colour-coded by status. A cluster of cuts at the same physical point becomes visible geographically — not just as matching distances in a table.

The route between the control room and the line's end can be confirmed too: pick the right one from the road routes suggested, or trace the cable's real path by hand when it doesn't follow a road. We keep that mapped route distance separate from the cable length on purpose — real cable is almost always longer once slack and vertical runs are counted.

What We Deliberately Left Out

Fiber tracking is an opt-in module an operator switches on when it's useful to them. Readings are photo-based rather than raw .sor trace files, and incidents are a staff-facing tool — customers never see them. We'd rather ship a small, reliable record that technicians actually fill in than a complex one they skip.