Fiber network monitoring
Fibre network monitoring is the loop that runs from the moment a fault is detected — by an alarm, a transmission team or a customer — through dispatch, arrival, diagnosis and restoration, with the elapsed time measured against the service level the affected customers are owed.
Detection is only the first minute
Most operators detect faults quickly. Alarms arrive, transmission notices a path down, or customers begin calling. The time that actually determines mean time to repair is spent afterwards: identifying which physical section is affected, deciding who goes, getting them there, and confirming they are working on the right enclosure.
Monitoring that stops at detection therefore measures the wrong thing. What matters operationally is a single record per incident that carries the fault from its first report to its verified closure, with every step timed.
The repair clock has to be honest
A repair timer that runs regardless of circumstance is quickly ignored. Crews are genuinely blocked: a landowner refuses access, police close a road, a storm makes a splice impossible, a vehicle breaks down. If those hours count as response time, the numbers stop describing performance and start describing luck.
The workable answer is a clock that can be paused, but only against a fixed list of reasons, recorded as events with a start and an end. That keeps the measurement fair without letting it become a free-text excuse field. It also produces its own report: if a third of the paused hours across a region are access refusals, that is a stakeholder-engagement problem, not a field-operations one.
- Elapsed repair time is computed from the open time minus accumulated paused time.
- Each pause carries one reason from a fixed list — access, weather, vehicle, fuel, equipment, traffic, compound fault or escalation approval.
- Pauses are events, so the record shows who paused, when, and when it resumed.
Measure in the database, not the browser
SLA timing that is calculated in the user interface produces a different answer on every screen: a laptop with a slow clock, a tab left open overnight, a phone that was offline for an hour. Because breach status can carry commercial consequences, it has to be computed server-side from recorded timestamps and pushed to displays, not derived locally.
Reporting that survives a dispute
Monthly SLA reporting is where the record is tested. A credible report can show, for any individual ticket, when it opened, who was assigned, when they arrived, what they found, what they did, what evidence they captured and exactly which minutes were paused and why. If any of that is reconstructed after the fact, the report is an assertion rather than a record.
How FiberOps monitors and times repairs
FiberOps treats an outage as an append-only timeline. Nothing is overwritten, so the state of a ticket is always explainable by the events that produced it.
- Seven ticket states with enforced transitions, so a job cannot jump from open to closed without the steps in between.
- SLA tiers of two, four and eight hours, with elapsed time computed in the database every minute and streamed to dashboards.
- Thirteen fixed pause reasons, each recorded as a paired pause and resume event.
- A repair dashboard showing status, assigned technician, arrival proof, pause reasons and breach state, exportable for reporting.
Common questions
- What does fiber network monitoring include?
- Fault detection, incident creation, dispatch, arrival confirmation, diagnosis, repair, evidence capture and verified closure — with elapsed time tracked against the service level for each affected customer.
- How should SLA time be paused during a repair?
- Only against a fixed list of reasons, recorded as a pause event and a matching resume event, so the paused minutes can be audited later and reported on by reason.
- Why should SLA timing be calculated server-side?
- Because breach status has commercial consequences and browser clocks, offline periods and stale tabs all produce different answers. Computing from recorded timestamps in the database gives every viewer the same number.
More answers are on the fiber operations FAQ.
Related reading
See it on your own network
We will walk through your plant data, your SLA tiers and your field workflow — not a generic demo dataset.