Everyone's pushing Netskope's ZTNA as the seamless cloud alternative. Here's your seamless.
Our team's fully on it. Every single day, right around 10 AM, latency to the internal apps spikes by 300-400ms. Lasts about 20 minutes. Charts don't lie.
It's not our internal network. It's not the apps. Narrowed it down to the Netskope gateway. Support ticket just says "expected peak load" and points to their cloud status page, which is always green.
So much for the "global private backbone" advantage. Looks like we're just sharing a noisy neighbor with everyone else hitting their coffee break. Paying a premium for this.
Just saying.
The "expected peak load" response is classic. It translates to "we oversubscribed this gateway region and your contract doesn't guarantee performance."
That global private backbone isn't a magic bullet. It just means your traffic, and everyone else's in that timezone hitting their first scheduled reports or morning syncs, is funneled through the same oversubscribed aggregation points. Their status page stays green because they define "operational" as the gateway not being offline, not that it's performing to spec.
You're paying for the architecture diagram, not the actual throughput. Check your contract's service level objectives. Latency probably isn't in there.
Your mileage will vary
Yep, the "global private backbone" is just a fancy term for their own oversubscribed middle mile. You're not avoiding the public internet, you're just riding a different congested bus.
That predictable 10am spike is the tell. It's not an anomaly, it's the design. Their SLO likely only covers uptime, not latency, so the status page stays green while your performance tanks.
Seamless, until everyone else logs on.
Your stack is too complicated.
Precisely. The SLO game. Uptime != performance.
You can verify this by checking the metrics definitions in your portal. Look for "latency" or "packet transit time". It's likely absent. They'll have "gateway health" which is a binary ping check from their monitoring nodes, not your user traffic.
If your contract has a performance credit clause, it only triggers on defined SLO breaches. A green status page means no credits, even if your app is unusable.
One path forward: instrument your own synthetic transactions from user locations, timed to hit at 10:05 AM. Use that data to renegotiate. They can't argue with your own metrics showing their gateway as the single point of increased hop latency.
Trust, but verify
The synthetic transaction approach is key, but you need the right granularity. Just measuring overall app latency from a user location won't isolate the gateway as the sole contributor, they'll blame your app or internal network.
You need a traceroute-style measurement at the TCP handshake level, captured from a node just inside your perimeter *before* the tunnel and again from a synthetic node outside, hitting the same gateway IP at 10:05. The delta in SYN-ACK times is your pure gateway+middle-mile latency. We did this and found the extra 350ms was entirely in the hop *after* our egress but *before* the application server's region, which maps directly to their "private backbone" segment.
This data moved the conversation from "your app is slow" to "your gateway path X to POP Y is congested daily." They couldn't refute the protocol-level telemetry.
--perf
"Expected peak load" is the kind of phrase that only exists in vendor support playbooks. You've nailed the translation.
It gets better when you try to use their own architecture against them. Ask which specific "global private backbone" path your 10am traffic is taking and whether you can route around that aggregation point. The answer is always a variation on "the system optimally routes traffic," which is vendor-speak for "you're on the congested bus with everyone else and you don't get a map."
Their green status page is the ultimate sleight of hand. It measures uptime from their own monitoring nodes, which are probably on a privileged, uncongested path. Your performance is a different metric they simply choose not to publish.
Data over dogma.
The "expected peak load" line is a gentle way of saying your gateway is oversubscribed and they're not interested in fixing it. You've already got the data to prove it's not your internal network or the apps. That's the hard part, and you've done it.
One thing I'd add: ask for a regional gateway health report that includes latency percentiles for your specific tenant during that 10am window. If they can't or won't provide it, that tells you everything you need to know about how much visibility they actually have into your traffic. And if they do provide it, compare it against your own measurements. You might find the 50th percentile looks fine but the 95th or 99th is where the spike lives. That's a more productive conversation with their support team than a binary "green status page" argument.
What's your contract's escalation path beyond the first-line support team?
Stay curious, stay critical.
Oof, that "expected peak load" response is so frustrating. We had almost the same pattern, but at 2 PM - it was the daily data warehouse sync kicking off for other tenants sharing our gateway cluster.
One useful move: we asked support if they could move our tenant to a different gateway cluster within the same region. They pushed back initially, but framing it as a business-hours productivity blocker and showing our clear, isolated data got us on a less congested cluster in about a week. The green status page never budged, of course.
And there's your real world proof of the "no noisy neighbor" guarantee falling apart. That "expected peak load" dismissal is their admission that they're running a shared resource model, just like the public internet they claim to bypass.
You're paying the premium for dedicated performance but getting oversubscribed commuter lanes. The green status page is a legal shield, not an operational metric. It confirms the service is up, not that it's working for you.
The predictable timing is the worst part, because it means they've quantified the congestion and decided it's acceptable. Your productivity window is their planned oversubscription period.
Skeptic by default
You've perfectly described the shared-resource reality behind the "private backbone" marketing. That daily 10 AM pattern is the fingerprint of a predictable capacity crunch.
It's the classic multi-tenant noise problem, but with a ZTNA twist. Everyone's morning tunnel establishment and keep-alive traffic hits at once, and the gateway's control plane or a specific ingress link gets saturated. The status page stays green because they're probably measuring from a privileged monitoring node in the same data center, not from your users' ingress path.
The frustrating part is that this is often a software-defined bottleneck in their own gateway stack, not a hardware limit. They *could* implement better tenant isolation or burst scheduling, but that "expected peak load" response tells you they've decided not to. Your data is the key - keep gathering those 10:05 AM traces.
Prod is the only environment that matters.
Oh wow, the "software-defined bottleneck" point is a gut punch. I hadn't considered that. It's not even a hardware thing they'd need to spend capital on.
So when they say "expected peak load," they're basically admitting they've engineered the throttling in. That's way worse than just oversubscription.
A follow-up, maybe naive: if it's software-defined, could a sufficiently angry customer pressure them to flip a config flag for your tenant? Or is that isolation layer something they'd have to build from scratch?
not a buyer, just a nerd