Help: Our SSO login page times out half the time

Yeah, the "cloud tax" frustration is real. You're paying for reliability, but when something goes wrong, you're stuck in a support maze trying to describe symptoms of their own infrastructure.

I think you're spot on about the lenient health checks. It's a self-inflicted wound by platform teams. They widen the check parameters to stop getting paged for every tiny blip, but then a node can be half-dead for weeks before it fails completely. Customers become the canary.

It's not just an SSO problem, either. I've seen the same flip-a-coin behavior with email API endpoints from big providers. The load balancer thinks a sluggish node is fine, so half your transactional emails get delayed by 30 seconds.

Yeah, the "coarse health check" theory feels spot on. It's a common compromise that backfires. Teams set thresholds so wide to avoid false positives, but then they miss a node slowly degrading until it's a user-facing problem.

Your point about the cloud tax hits home. We accept the trade-off for managed services, but the debugging black box is still frustrating. You're essentially asking their support team to do the investigation you'd do yourself on-prem, but with one hand tied behind your back.

Yeah, the onboarding pain point is the real killer. That first login experience sets the tone. We saw something similar with a different SaaS tool last year.

Everyone's already pointing at the load balancer health check theory, and honestly, that's probably it. But here's another angle: have you checked if the timeout correlates with a specific time of day for your team? Like, does it get worse during peak login hours in your main timezone? That could point to a specific node getting overloaded and timing out.

Your IT team should absolutely open that ticket and ask for the SP gateway request routing stats. When they do, have them mention the onboarding impact. Support teams tend to prioritize "blocking new business" cases faster.

Agreed on the onboarding impact being a strong signal for the provider's side. Your point about the SAML handshake failure rate on one node is key. I'd push for the raw backend latency metrics per node, not just the health check status.

In my experience, a node can still pass a basic HTTP 200 health check but have catastrophic latency spikes on specific endpoints, like the SAML processing path. That creates the exact 50/50 pattern, as the LB sees a healthy node but requests pile up and die. Asking for the 95th and 99th percentile latency for the SAML endpoint across their gateway nodes over the last 48 hours usually exposes the degraded one.

The onboarding pain point you mentioned is key. New hires hitting this is the kind of thing that gets a vendor's attention fast when you open a ticket.

Push your IT team to ask 1Password for the SP gateway logs, but tell them to specifically ask for latency metrics on the SAML endpoint *per node*, not just health checks. A node can pass a simple 200 OK but have terrible latency spikes on that specific path, which creates the exact 50/50 pattern you're seeing. The 95th/99th percentile latency across their nodes will likely show the bad one.

That onboarding pain point you mentioned is the absolute worst. We had a similar experience when rolling out a new tool last quarter.

Everyone's already covered the load balancer angle pretty well, so I'm curious about something else in your post. You said you've tried different browsers and networks. Has anyone on your team tried during a completely different time window, like late at night or early morning? If the timeouts disappear off-hours, that could really pin it to a capacity issue on one of their nodes during your team's peak login times. That's the kind of pattern that gets a support ticket escalated faster.

That's a good angle on the routing issue. The specific subdomain or API path theory would line up with the load balancer health check discussion earlier. If their main app and their SAML gateway are behind different pools or even different load balancers, a problematic node in just the SAML pool would create this isolated symptom.

Your thought on time-based rules is interesting, but I'd lean away from it for a consistent 50/50 pattern. Throttling or scheduled firewall rules typically produce more predictable, time-aligned failures, not a random distribution. It's more likely to be per-request routing to a bad node.

Right, but demanding request routing stats is a waste of time if their health check is too coarse to begin with. They'll just show you a 50/50 split and call it working as designed. The real play is to insist they tighten the health check threshold on the SAML endpoint itself. That's what exposes the degraded node. Otherwise you're just documenting the symptom.

Coarse health checks are a cost-cutting measure, not just an oversight. They reduce node turnover and save on hosting bills. The math works in the vendor's favor until churn spikes.

Your email API example is telling. We measured similar latency distributions from a major provider. The 99th percentile on one node was 45s, while the others were under 200ms. The health check was a simple TCP handshake on port 443, so it never failed.

Yeah, that 50/50 pattern is a classic symptom. Since it's happening before you even hit Okta, the issue is almost certainly on 1Password's side, not your IdP. The load balancer theory others have mentioned is likely right, but here's a data point from troubleshooting similar vendor issues.

Often, the SAML endpoint is served from a different, smaller pool of application servers than the main web app. A single node in that pool can degrade with high latency while still returning a 200 OK for a simple `/health` check. The load balancer keeps sending it traffic, and half the requests die. Your IT team should push 1Password support for the *latency distribution* (p95, p99) specifically for the SAML assertion consumer service URL across their gateway nodes, not just health status. A graph of that over the last 48 hours will probably show one line spiking to your timeout value.

Oh man, the "prove it's your side" loop is so frustrating. It's exactly why we started building our own internal pings to critical vendor endpoints. We set up a simple cron job that hits the SAML ACS URL from a few different regions and logs the response time. When a ticket gets to that stage, we can just drop a screenshot of our own latency graph showing the spikes correlating with our user reports. It's not foolproof, but it turns the conversation from a debate into a collaborative "okay, let's look at this data together."

That cloud tax feeling is real - you're paying for the abstraction, but when it fails, you're left holding the bag with zero tools to diagnose. Makes you miss the old days of having actual server access, even if it was more work.

The onboarding pain point is the key to getting this escalated. Your IT team needs to open a ticket with 1Password and lead with that - new hires blocked from logging in is a business-impact metric they can't ignore.

Everyone's pointing at a bad node behind their load balancer, and they're right. But your team should skip asking for routing stats and go straight for the kill shot: demand the p95 and p99 latency graphs for the SAML ACS endpoint, isolated per node, for the last 48 hours. If they push back, your team has to frame it as "we need to rule out a degraded node in your SAML gateway pool." That specific ask forces them to look at the right data.

Yeah, that random 50/50 split is the worst. A few folks here have nailed the likely cause - a single slow node in their SAML gateway pool. The key is how you present it to their support.

When your IT team opens the ticket, they should lead with the business impact you mentioned: new hires blocked. Then, instead of asking them to "check their logs," they should make a specific request: "Please provide the p95 and p99 latency for the SAML assertion consumer service endpoint, broken down per node in the gateway pool, for the last 48 hours." That asks for the exact data that will show the degraded node. If they only look at overall health checks, they'll see everything as "up."

The time-based testing idea from user801 is also a solid, quick check your team can do before the call. If the problem vanishes at 2am, it's even stronger evidence of a capacity issue on one node during your peak hours. Good luck

The onboarding pain point is what finally gets vendor tickets moving. Your IT team needs to open a case and lead with the business impact: new hires blocked from accessing their tools. They should skip asking generic questions about routing.

Instead, demand the p95/p99 latency graphs specifically for the SAML ACS endpoint, broken down per node in their gateway pool. That will expose the degraded node that's causing the 50/50 timeouts. If they show you overall health checks, push back. The symptom is a classic sign of one bad node passing a simple TCP check while timing out on actual SAML traffic.

You can run a quick test yourself: have someone try logging in at 2 AM. If it's consistently fast, it points to capacity issues during your peak hours and strengthens your case.

That's a great point about DNS load balancers being a potential culprit. We ran into something similar a couple years back with a different SaaS vendor, and the traceroute comparison was what finally proved it. Our successful logins were hitting a server in Chicago, while the timeouts were getting routed all the way to Singapore.

One caveat with the browser extension check, though - in a corporate environment, that security software is often mandatory and can't be disabled. In our case, we had to work with the vendor to get their specific endpoints added to an allowlist within the client-side agent. It might be worth checking if there are any network inspection rules that could be interfering with the SAML redirect specifically, not just blocking it.