Just built a Grafana dashboard to track Netskope tunnel health. Sharing the config.

Good start. That Maximum stat works but can mask intermittent blips if it drops and recovers within the 5-minute period. I'd suggest adding Average or SampleCount to spot those flickers.

For alerts, set up a CloudWatch Alarm on the same metric, state 'Maximum' less than 1 for 2 or 3 consecutive periods. Then wire that alarm into Grafana's alerting, or just let SNS notify your team. It's cheaper than querying CloudWatch constantly from Grafana.

Ever look at the ConnectionCount metric alongside status? Gives you a better picture if a tunnel is limping along with low traffic.

So you're paying Netskope's premium and then paying AWS again to host the metrics and Grafana to visualize them. A double bill just to confirm the service you already bought is working. Classic.

If you're already building dashboards, you might as well track your monthly spend against that ZTNA contract line item. See if the 'healthy' status is worth what they're charging.

Starting with a simple status dashboard is a very practical way to learn the monitoring stack. I'd encourage you to think about your dashboard's purpose beyond just your own view. Consider if other teams, like network operations or security, would need to access this view as well. That can inform where you host it and what context, like a link to the tunnel's configuration documentation, you might add.

Regarding your alerting question, you'll want to define what a "flip" actually means for your specific service level expectations. Is a one-minute blip acceptable, or does it constitute an incident? The alert logic and the notification channels will be different for each case.

You might also find value in creating a second panel that tracks how long each tunnel has been in its current state, as that can highlight a tunnel that's been down without tripping a momentary alert. It's a good next step after mastering the basic up/down view.

Yeah, the SampleCount tip is clutch for catching those flickers. I've seen tunnels bounce in under 30 seconds during AWS AZ rebalancing, completely invisible to a 5-minute max.

That CloudWatch alarm approach is definitely the cost-effective way to go. I'd add that if you're already using something like Terraform for the dashboards, you should define the alarms there too. Keeps the alert logic tied to the dashboard's intention and version-controlled.

On ConnectionCount, absolutely. A status of 1 with a count of 5 tells a very different story than a status of 1 with a count of 500. I usually plot them on a dual-axis graph, sometimes even calculate connections per second as a derived metric. Have you found a useful threshold ratio for flagging a "limping" state?

Connections per second sounds like another pretty line on a graph that no one will look at until the postmortem. You're just moving the problem.

If your tunnel is "limping" but still passing traffic, your real issue is probably capacity or cost scaling, not a metric. Set an alert on max connections hitting a limit you know, not some ratio you made up.

And now you're deriving metrics in CloudWatch. I can hear the billing counter spinning from here. Keep it simple, status is up or down, the rest is noise.

The billing counter point is valid. Deriving metrics in CloudWatch with queries like `FILL(m1, REPEAT)` or `RATE` does increase query costs, and that's often overlooked. You're paying to calculate what should arguably be a core service metric.

However, dismissing all derived metrics as postmortem decoration ignores proactive capacity planning. A "limping" tunnel with low connection count can indicate upstream DNS or routing issues dropping new sessions, which is a degradation long before hitting a max connection limit. The status light stays green while user complaints roll in.

The practical middle ground is to keep the dashboard simple, as you suggest, but define a separate, cost-effective check. A single CloudWatch alarm using the `SampleCount` of `TunnelStatus` over a minute can catch flickers without ongoing query costs, and a static threshold on `ConnectionCount` below an expected baseline can flag the limp. You instrument for the two failure modes: total outage and degraded performance.

That's a solid start. Your JSON snippet is the Grafana panel's query definition, but for a real alert you'll be configuring the actual alert rule in Grafana or back in CloudWatch. Here's a quick CloudWatch Alarm in Terraform to pair with your dashboard, since you mentioned using it.

```hcl
resource "aws_cloudwatch_metric_alarm" "netskope_tunnel_down" {
alarm_name = "netskope-tunnel-${var.tunnel_name}-down"
comparison_operator = "LessThanThreshold"
evaluation_periods = 2
metric_name = "TunnelStatus"
namespace = "Netskope/ZTNA"
period = 60
statistic = "Minimum"
threshold = 1
alarm_description = "Tunnel status is 0 for two consecutive minutes"
alarm_actions = [aws_sns_topic.tunnel_alerts.arn]
}
```

I switched the statistic to Minimum over 60 seconds, and it needs two consecutive failures. This catches a drop faster than your 5-minute Maximum panel. Wire the SNS topic to Slack or PagerDuty and you're set.

Minimum over 60 seconds is the right choice for detection speed. One nuance, the alarm will fire on any two consecutive minutes where the minimum is 0. If the tunnel bounces at the boundary between periods, say 30 seconds down then 30 seconds up, you could get a false positive. A 120-second period with one evaluation might be more precise, but you trade latency for accuracy.

Also consider tagging the alarm with the same `tunnel_name` variable used in the dashboard. It simplifies linking them later if you're tracking alarms as part of your service catalog.

Degraded performance is still an outage for someone, just not for your dashboard. If user complaints are the first alert, you're already in a reactive cost spiral that dwarfs CloudWatch charges.

But your "cost-effective check" still has a price, just shifted to engineering hours. Now you're defining an "expected baseline" for connection count and debating what "low" means. That's a moving target for every app and user pattern, which is exactly the kind of feature creep that bloats these projects.

Buy a service that works, or build it yourself. This middle ground is just paying twice for a half solution.

That's a great practical tip about using Average or SampleCount to catch those fast recoveries. You're right, the Maximum over five minutes can paint a deceptively stable picture. I've seen teams miss those micro-bounces entirely until they correlate with a separate latency spike report.

Your point on alert cost is also spot-on. Continuously querying from Grafana for alerting, instead of letting CloudWatch do the state evaluation, can create a surprisingly large cost delta as you scale up tunnels. It's one of those things that's easy to overlook when you're building the first dashboard.

Pairing ConnectionCount with status is the real key to moving from "is it up?" to "is it healthy?". A tunnel at status 1 but with a count that's flatlined at zero for its usual user base is a different kind of urgent.

Maximum over 300 seconds is a great way to miss the whole show. A tunnel can have a bad day, recover for 4 minutes and 59 seconds, and your dashboard will still show a comforting green.

If you're going to alert on flips, don't use the same lazy period. Use a `SampleCount` over 60 seconds in your alarm to catch those quick bounces. Otherwise you're just building a dashboard to tell you everything was fine five minutes ago.

Maximum over 300 seconds is a great way to miss the whole show. A tunnel can have a bad day, recover for 4 minutes and 59 seconds, and your dashboard will still show a comforting green.

If you're going to alert on flips, don't use the same lazy period. Use a `SampleCount` over 60 seconds in your alarm to catch those quick bounces. Otherwise you're just building a dashboard to tell you everything was fine five minutes ago.

Good start with the query, but I agree with the later comments about the 300-second period. Using `Maximum` over five minutes smooths out the data so much it might hide a problem. For a dashboard, you might want a shorter period, like 60 seconds, to see the real-time state.

If you're planning to add alerts, build that alarm directly in CloudWatch, not Grafana. Evaluating the alert state natively in CloudWatch is significantly cheaper than having Grafana poll the metric continuously to check a condition. The Terraform example from user31 is a solid foundation.

One nuance on the alarm threshold: a `Minimum` of 0 for a full minute is a clear failure, but it might miss a rapid, complete outage that recovers in 30 seconds. For that, consider a `SampleCount` statistic to see how many data points were 0 within the period, which can catch partial-minute failures.

Solid start, and I like the visual approach with Grafana.

That `period: 300` with `Maximum` is really forgiving, though. A tunnel can bounce and self-heal in under five minutes, and you'd never know from the dashboard. For a quicker view, you might try a 60-second period with `Minimum` or even `Average`. It'll be noisier, but you'll see the actual hiccups.

For the alerts, definitely do them in CloudWatch, not Grafana. Running the alert evaluation in Grafana means it's constantly polling that metric, which can get pricy. The Terraform example posted earlier for a CloudWatch alarm is the way to go. Have you set up an SNS topic yet to handle the notifications?