Nile Portal Dashboard Overview: Fast-Track Root Cause Analysis

Transcript:

This dashboard is the first thing you see when you log into the Nile portal. At a glance, it tells you the health of your entire network, across all your sites, all in one place.

Before I walk through each tile, I want to establish two terms we use at Nile, because they map directly to what you're seeing on this screen.

The first is Core — Core is what Nile delivers: secure wireless and wired connectivity as a service.

The second is Context — Context is everything that supports the Nile service. Your Internet connection, DHCP, DNS, RADIUS, end-user devices, and applications. We don't own those unless you sign up for Nile DHCP or RADIUS, but we monitor them, because they directly affect your users' experience.

Keep those two in mind as we go through the tiles.


We don't expect you to live in this dashboard. This isn't something you're checking every morning with your coffee.

But here's the scenario where you will open it — an end user calls and says something isn't working. And the very first question everyone asks is: is the network the problem? The network is always blamed first. It's guilty until proven innocent.

So the workflow is simple. First — is Nile, the Core service, the issue? If not, is it something in the Context — Internet, RADIUS, DHCP? If that's fine too, then is it the end-user device? Or a specific application?

You want to rule out the network and infrastructure before you start digging into devices or apps. That's exactly what this dashboard is designed to help you do, fast.

And the way we make that possible — we proactively monitor your network, infrastructure, and applications every minute, using physical and virtual sensors deployed across your environment. You're getting a continuous, outside-in view of everything, not just when something breaks.


Now, one more thing before I go through the tiles — every card and button on this screen is a filter. When I click something, the map below updates to show only the buildings affected by what I clicked. That's a really important concept, so watch how that plays out as we go.

The map here shows all your sites geographically. Right now I have three buildings — SJC-BLDG-1 out here in San Jose, TX-BLDG-1 in Texas, and BLR-BLDG-1 over in Bangalore. The color of each pin tells you its status — green means healthy, red means there's an active incident.


The first tile is Nile — this is the Core service tile. It answers that first critical question: is Nile the problem? We track three things here: Availability, Capacity, and Coverage.

Availability shows the percentage of time your clients can actively pass traffic through the Nile service. Coverage shows the percentage of time your entire site has video-conferencing grade signal — that's -67 dBm or better. And Capacity indicates the percentage of time we're meeting our capacity commitments on the floor.

Right now I'm showing 100% across all three, which means the Nile service itself is performing perfectly. We measure all of this using physical sensors and the third radio on our APs — essentially a synthetic client probing the network every minute, from the outside in.


The second tile is Infrastructure — this is the Context side, and this is where things get interesting today, because we actually have 2 incidents flagged. Infrastructure covers everything that supports the Nile service: your Internet connection, RADIUS, DHCP, DNS, and WiFi air quality.

Every minute, we're running synthetic transactions against each of these services. We don't just capture whether something is up or down — if it's up, we're also measuring the latency of those transactions. And if anything falls outside expected thresholds, we generate an alert right away. Take DNS for example — every minute, we're sending real UDP 53 queries and measuring whether they resolve, and how fast.

One area worth calling out specifically is WiFi air quality. Wireless interference is one of the most frustrating and intermittent problems to troubleshoot. Nile continuously monitors and reports on air quality, looking for interference and congestion — and our channel planner will proactively change channels if we detect a problem.

Now back to what we're looking at — DNS and DHCP are both showing red with 1 incident each. Watch what happens when I click DNS — [click] — the map immediately filters to show only the buildings where DNS is the problem. TX-BLDG-1 is red, which tells me that building has a DNS incident right now. San Jose and Bangalore look clean from a DNS standpoint.

Once I click into that building, I can drill all the way down to the floor level to see exactly what's going on — but we'll save that for another part of the demo.


The third tile is Devices — this is where end-user experience shows up. It shows what's happening at the device level in terms of DHCP, DNS, RADIUS, or any other user errors.

For example, if a user is having trouble getting a DHCP IP address, we're monitoring the actual transactions between the DHCP server and the device — so we'll generate an incident the moment that fails. Same with RADIUS authentication. This tile also shows how many users are impacted when a shared service like DHCP or RADIUS goes down, so you immediately understand the blast radius.

Same filtering mechanic applies here — click a card, and the map tells you exactly which buildings have users affected right now.


And the fourth tile is Applications — this shows the health of your top consumed applications at that site. You can see Google, Zoom, Salesforce, AWS, and others listed here. We have a deep application inspection engine that recognizes more than 3,500 applications traversing your network. We proactively run HTTPS transactions directly with the top 10 application — so if there are any reachability or latency issues, we create an incident automatically. We also have the ability to monitor custom apps that run in your datacenter. In this example Nile-Webapp and Nile CRM are custom applications.

And I'll share a real story that shows why this matters. Back in October 2021, we had just deployed Nile at a social media company. It was their first day back in the office after the pandemic — big day, everyone's excited to be back. Users started reporting they couldn't connect to Facebook. The IT team's instinct, naturally, was to start looking at the network.

But our dashboard told a different story immediately. Everything was green — Nile, Infrastructure, Devices — except for one thing: Facebook. Our sensors had already been running HTTPS transactions with Facebook every minute, and those transactions were failing. The network was innocent.

Sure enough, Facebook had a major outage on October 4th, 2021 — but that wasn't officially declared until hours later

Imagine how much time that saved the customer. Instead of spending hours chasing a network problem that didn't exist, they had their answer in minutes. And honestly — you never expect Facebook to go down. But when it does, you'll know before anyone else tells you.

 


So to bring it all together — the flow is: Core first, then Context. Is Nile the issue? Is it Infrastructure? Is it a Device? Is it an Application? You rule out the network, then work your way out. Everything here is based on proactive synthetic transactions. You're not waiting for users to complain — Nile already knows."