Stop Blaming the Network! How Nile Pinpoints Application Outages in Seconds

Transcript: 

"Welcome back. In this video we're going to drill deeper into the Applications tile.

As you already saw in the previous video, Nile has virtual sensors embedded in our headend. These sensors proactively monitor the top 10 business applications every minute — running HTTPS transactions to check whether each application is reachable and measuring the latency of those transactions.

You'll also notice that the list isn't just out-of-the-box applications. You can customize it with your own internal apps. Here for example, you can see Nile-CRM and Nile-WebApp — those are customer-specific applications that we've added to the monitoring list alongside the standard ones like Google, Zoom, Salesforce, and AWS.

Now let's drill down into one of these buildings to see the minute-by-minute data we're collecting.

 

"So now we're at the building level. And if you look at the Events panel on the right, you'll notice there are quite a few events logged here — issues with Salesforce, GCP, Zoom, AWS, Nile-CRM, and others at various points in the last couple of hours.

Now you might be wondering — if there are all these events, why doesn't the landing page show any incidents for Applications? Great question.

Here's an important distinction we make at Nile: we record every anomaly, but we only alert on incidents. An incident is defined as 5 consecutive minutes or more of errors. So if a service has a hiccup that lasts 2 minutes and recovers — we've captured it, it shows up in the Events log, but it doesn't rise to the level of an incident on the landing page.

Looking at the events here, every single one lasted less than 5 minutes. So while we have full visibility into each of those anomalies, none of them crossed the threshold to generate an incident. That's by design — we don't want to cry wolf on transient blips that self-resolve.

 

"Now let's click into one of these applications to understand what was actually happening. Let's pick Salesforce.

So what we can see here is that Salesforce was actually available the entire time — the availability bar is green throughout. But look at the performance graph — you can see spikes in latency during the HTTPS transactions, well above the normal baseline. Those red markers are the moments where the experience was degraded.

This is really valuable data. You can now correlate this against your Internet tile — if you saw similar latency spikes on your Internet connection at the same time, that tells you the issue was likely upstream, on the Internet path. If the Internet looked clean, then the latency is coming from Salesforce itself, and there's nothing you could have done on your end.

That correlation is what lets you quickly rule out your own infrastructure and point the finger in the right direction.

 

So to bring this all together — the virtual sensor in our headend is proactively running HTTPS transactions every minute against your top applications, measuring both availability and latency. We capture every anomaly in the Events log, and we surface an incident only when something persists for 5 minutes or more.

So the next time a user calls saying they can't connect to an app or it feels slow, you don't need to guess. Come here, look up the time window, and see exactly what our sensors were seeing at that moment. You'll know within seconds whether the application was the problem — or whether you need to look somewhere else."