Bringing Geographic Context to Network Operations

At Grant County PUD Telecom, the data needed to understand network outages already existed. The problem was that it lived in separate systems. Zabbix showed hub status and monitoring health. ArcGIS showed hub locations, fiber patch locations, and service-area boundaries.

Each system was useful on its own, but during an outage, operators still had to connect the dots manually. A monitoring alert could show that a hub was down, but understanding where that hub was located and which areas or ISPs might be affected required jumping between tools.

That became the core problem:

How do we turn network monitoring data into geographic operational context?

The problem

A traditional monitoring alert is useful, but it is not always enough. If a hub goes down, Zabbix can tell you the device is unreachable or that a trigger has fired. But the alert alone does not immediately answer the next operational questions:

• Where is the affected hub?
• What service area does it support?
• Are nearby hubs also impacted?
• Is this isolated or part of a larger outage?
• Which ISPs or customers may need to know?
• Is this related to a storm, maintenance event, or broader network issue?

Those questions are geographic and operational, not just technical. The network team had the monitoring data. The GIS team had the location and service-area data. The missing piece was a shared view that connected both.

The goal

The goal was to build a real-time operational map that joined hub monitoring status with GIS context. The map needed to help different groups answer the same basic question:

What is affected, and where?

For network administrators, that meant faster outage triage. For field technicians, that meant clearer geographic awareness. For ISPs, that meant better communication around possible service impact. For management, that meant a faster high-level view of outage scope.

The goal was not to replace Zabbix or ArcGIS. The goal was to connect them in a way that made outage information easier to understand.

The initial concept

The first version focused on a simple idea: take hub status from Zabbix and display it on a map using GIS location data. That required three pieces of information:

1. The hub status from Zabbix
2. The physical hub location from ArcGIS
3. The service-area boundary associated with that hub

Once those pieces were connected, the map could show more than whether a hub was up or down. It could show where the affected hub was and what area might be impacted.

Data sources

The map depended on two main systems.

Zabbix

Zabbix provided monitoring data for telecom hubs — host status, availability, and alert state. It was the source of truth for whether a monitored hub was healthy or unhealthy.

ArcGIS

ArcGIS provided the geographic context. The important layers included hub or fiber patch locations and service-area polygons. These layers connected a monitored hub to a physical location and a broader affected area. Fields such as hub name, site code, facility ID, and hub number became important because they were used to match monitoring objects to GIS features.

The matching problem

The hardest part was not displaying data on a map. The harder part was joining data from two systems that were not originally designed around the same naming model.

Zabbix had hub names and monitored hosts. ArcGIS had GIS features with fields such as name, site code, facility ID, and hub number. To make the map useful, those values had to be normalized and matched carefully — a hub in Zabbix needed to resolve to the correct GIS point and service-area polygon.

That meant the project was not just a front-end map. It was also a data-correlation problem. Bad matching would create bad operational information: if the wrong hub was linked to the wrong service area, the map would be worse than useless during an outage.

Early build

The early prototype used a custom web application approach. The stack included:

• React
• TypeScript
• Vite
• MapLibre
• Zabbix API integration
• ArcGIS data
• Environment-based configuration

The app focused on displaying hub status visually, supporting search, clustering map features, and refreshing status data. The prototype proved the value of the idea: hub monitoring became much easier to understand when viewed geographically.

Security considerations

The project also had security constraints. Zabbix and ArcGIS both required authenticated access, and exposing tokens directly in a browser-based app would have been a bad design. The safer approach was to avoid putting sensitive credentials in client-side code.

The planned architecture included a separate API layer that could proxy requests, cache data, handle token rotation, and keep secrets server-side. That would also make it easier to control which data was exposed to the browser. Important considerations included:

• Avoiding exposed Zabbix API tokens
• Avoiding exposed ArcGIS tokens
• Using service accounts where appropriate
• Separating development and production configuration
• Planning for token expiration and rotation
• Keeping the browser-facing app limited to the data it actually needed

Pivot toward ArcGIS

As the project evolved, ArcGIS became a stronger part of the solution. Instead of treating ArcGIS as just a background data source, the better path was to use more of the ArcGIS platform directly — maps, layers, popups, labels, lists, and Experience Builder functionality.

This made sense for a few reasons. First, the GIS data already lived in ArcGIS. Second, ArcGIS already handled mapping, authentication, layer rendering, and user interaction well. Third, using native ArcGIS capabilities reduced the amount of custom infrastructure needed just to display and interact with GIS data.

The custom app approach proved the concept. The ArcGIS-centered approach made the solution more aligned with the existing enterprise platform.

User experience

The user experience needed to stay simple. During an outage, users do not need a complicated dashboard — they need fast answers. The map needed to make status obvious:

• Healthy hubs should be visually distinct from unhealthy hubs.
• Affected areas should be easy to identify.
• Hub names and site codes should be searchable.
• Clicking a hub should show useful context.
• Service-area boundaries should help explain possible impact.
• The view should support both technical troubleshooting and non-technical communication.

The goal was not to overload the map with every possible field. The goal was to show the right information at the right time.

Operational value

The biggest value of the Hub Map was shared context. Before the map, an outage required people to mentally connect information across monitoring tools, GIS layers, and internal knowledge. After the map, the relationship between network health and geography became visible.

That matters because outage response is not just about identifying a failed device. It is about understanding impact. A hub outage is more meaningful when you can see:

• Where it is
• What area it serves
• Whether nearby hubs are affected
• Whether the outage pattern matches a storm path or known maintenance event
• Whether ISP communication may be needed

This is where the project moved beyond a technical dashboard. It became an operational tool.

What made this project different

The Hub Map was not valuable because it used a modern front-end stack or because it connected to an API. It was valuable because it connected systems that were previously separate.

Monitoring data became location-aware. GIS data became operationally active. Outage information became easier to communicate. That is the kind of automation and integration that matters in infrastructure work: not flashy software for its own sake, but tools that reduce friction during real operational events.

Outcome

The Hub Map gave network operations a better way to understand outage scope and location. It helped turn isolated hub alerts into a shared geographic view that could be used by network administrators, field teams, ISPs, and management. Instead of asking people to move between systems and mentally assemble the picture, the map brought the picture together.

What I would improve today

If I rebuilt or expanded the project today, I would focus on a few areas:

• Formalize the API layer for secure server-side token handling
• Add structured caching for Zabbix status data
• Improve matching logic between Zabbix hosts and ArcGIS features
• Add stronger validation for unmatched or duplicate hubs
• Build a clear admin workflow for correcting bad mappings
• Add outage history and timeline views
• Add role-based views for internal teams versus ISP-facing summaries
• Add better mobile views for field use
• Add alert-to-map deep links from Zabbix
• Track map usage during events to see which views are most useful

The core idea would stay the same: connect monitoring status to geography so teams can understand impact faster.

Tools used

• Zabbix
• ArcGIS
• ArcGIS Experience Builder
• GIS service layers
• React
• TypeScript
• Vite
• MapLibre
• API integration
• JSON data mapping
• Environment-based configuration

Final takeaway

This project reinforced a simple lesson: infrastructure teams do not just need more alerts. They need better context.

By connecting Zabbix monitoring data with ArcGIS location and service-area data, the Hub Map turned network health into something teams could see, understand, and act on faster.