How we monitor uptime across our network

Customers ask a fair question: when we say the network is up, how do we know?

This post walks through how MegaLink watches the network in practice — not a product pitch, but the operational picture. If you run infrastructure for a school, hotel, or SME, some of these patterns will look familiar.

What “uptime” means to us

Marketing likes a single number. Operations needs a stack of signals.

We care about different layers:

1. Core and backhaul — links that carry traffic between sites
2. Access network — towers, sectors, and fiber aggregation points
3. Customer edge — CPEs, routers, and last-hop health
4. Services — DNS reachability, captive portals, support tooling

A tower radio can be fine while a single customer radio is misaligned. A fiber POP can be healthy while a misconfigured firewall blocks one VLAN. Monitoring has to show both the big picture and the awkward edge cases.

The monitoring loop

At a high level the loop looks like this:

Probe → Collect → Alert → Diagnose → Fix → Verify → Note

Skipping “Verify” or “Note” is how teams repeat the same outage three weeks later.

Probes we rely on

• ICMP / latency checks to key hops and customer-facing gateways
• SNMP or vendor APIs for radio SNR, traffic counters, and hardware health where available
• Synthetic HTTPS checks against a few always-on endpoints
• Heartbeat from critical on-prem boxes (monitoring hosts should not only live in one place)

What we watch for

Raw “host down” alerts are necessary but blunt. More useful thresholds include:

• Sudden latency spikes on a backhaul path
• Packet loss climbing on a sector during busy evening hours
• Optical power drifting on a fiber handoff
• Capacity nearing fair-use thresholds before users feel pain

A simplified topology sketch

Probes sit beside the data path, not only on it. If the path we use to send alerts is the same path that just died, we want a second way to know.

Alerting without chaos

Too many alerts train people to ignore them. Too few and you discover issues on Twitter.

Practical rules we aim for:

• Page a human for customer-impacting or cascading failures
• Ticket or queue for degradations that need a planned fix
• Suppress flapping alerts once acknowledged and while repair is underway
• Prefer actionable text: where, symptom, likely blast radius, first check

A good alert names a site or sector a technician recognizes — “Karagita AP-2 SNR drop” beats “Device 14 warning”.

Field reality in Naivasha and Limuru

Lab diagrams meet dusty roofs and generator schedules.

Things that show up in real tickets:

• A customer moved an outdoor radio “just a little” to clean the wall
• Trees grew into a fresnel zone after a rainy season
• Power blipped at a site and the radio came back with a stale config
• A hotel’s internal Wi‑Fi was the bottleneck, not our WAN

Monitoring does not replace a site visit. It tells you whether to drive and where to start looking.

Customer-facing honesty

When something breaks, silence is worse than a short status update.

Internally we track:

• Detection time
• Acknowledgement time
• Mitigation time
• Full restore time

Those timestamps are how you improve. They also keep support and field teams aligned so customers hear one story.

What we are improving next

No monitoring stack is finished. Near-term priorities for us look like:

• Richer historical charts per sector for capacity planning
• Cleaner customer-status language when a whole area is affected
• Tighter coupling between install quality checks and later reliability metrics

Takeaways

• Uptime is a layered claim — measure each layer.
• Alert on customer impact and precursors, not every counter twitch.
• Keep a verification and notes habit after every incident.
• Local context (power, foliage, roof mounts) belongs in the ops playbook, not only in tribal knowledge.

If you want a deeper dive next — for example how we think about capacity planning on shared wireless sectors — tell us what would help your team most, or follow along on the Engineering section.