We've been running PingFederate and PingDirectory in a multi-region Kubernetes cluster for 18 months, serving ~5k internal users and 2M external customers. Here's the raw data.
**The Good (Why we haven't ripped it out)**
* Solid uptime. Achieved 99.95% over the period, excluding planned maintenance.
* The directory is fast and stable. LDAP operations are consistent, even under load.
* Kubernetes Operator works, mostly. Deployments and failovers are automated.
**The Bad (Where the cost feels unjustified)**
* Observability is a joke. Their metrics are a black box. Had to build our own exporters to get usable Prometheus alerts.
* The "cloud-native" claim is stretched. Resource footprints are huge. Example pod request for a mid-tier instance:
```yaml
resources:
requests:
memory: "4Gi"
cpu: "2000m"
```
* Support is slow for real engineering issues. You get architecture docs, not root cause analysis.
**The Ugly (Incident Triggers)**
* Certificate rotation via their Helm charts caused a 14-minute partial outage. Rollback procedures were not documented.
* Alert fatigue from their default health checks. Had to rewrite all SLOs and error budgets based on *actual* user impact, not Ping's "health" status.
**Verdict**
If you need a battle-tested directory and a SAML/OIDC provider, it's competent. But you are paying a premium for the brand, not for superior tech. You will spend significant engineering time building the operational maturity they should provide.
For our next budget cycle, we are evaluating alternatives. The cost does not map to the value delivered for our use case.
I'm an SRE on a team managing identity for a SaaS platform with a similar scale (roughly 3k employees, 1.5M external users). Our production stack runs a mix of PingFed, Okta, and some open-source auth services on EKS, handling about 5B auth events a month.
Here's a breakdown based on running Ping for about three years and evaluating alternatives last renewal cycle:
* **Real Cost Beyond Licensing:** The enterprise list price bands are one thing, but the hidden operational cost is real. We spend approximately 15-20 hours a month on average on monitoring, custom scripting, and resource tuning that we don't with other managed services. The per-core licensing also forces oversized pod requests, as you noted, which cascades into higher k8s node costs.
* **Where It Clearly Wins:** For complex, stateful identity provider (IdP) orchestration and legacy LDAP directory requirements, it's hard to beat for raw stability. Our PingDirectory handles ~8k LDAP operations/sec per node with consistent sub-10ms p95 latency for reads, which we haven't matched with open-source options without significant sharding work.
* **Deployment & Integration Gotcha:** The Kubernetes Operator is functional but brittle during config changes. A specific limitation: updating a data source configuration often triggers a full pod restart instead of a live reload, causing a brief traffic drop. We had to implement a blue-green deployment pattern ourselves to avoid this, adding complexity.
* **Support & Escalation Reality:** For tier 3 support (outages, corruption), we've had good results, but for tier 2 (your observability black box), it's slow. A ticket about unexplained latency spikes in the metrics took 11 days to get a useful engineering answer. For real-time issues, you need your own deep instrumentation.
Based on your post highlighting uptime and directory performance as critical, I'd keep Ping for the core directory but recommend offloading the federation workload to a more cloud-native provider if your main pain is around ops and observability. To make a clean call, tell us: 1) what percentage of your external auth flow is standard OIDC/SAML vs. custom LDAP, and 2) whether your team has bandwidth to manage a multi-vendor identity stack.
That hidden operational cost is what's killing me right now. You mentioned 15-20 hours a month on custom scripting and tuning - we're seeing the same, but it's also creeping into our developer velocity. Every time we need to integrate a new app, there's a week of fussing with the PingFed adapters that just doesn't happen with our Okta setup for standard SAML/OIDC.
Your point about the operator being functional but... I'm guessing the sentence got cut off, but I'm betting it ends with "a pain to debug" or something similar? 😅 The lack of clarity in their logging makes troubleshooting those deployment hiccups a real time sink.
The grass is greener? We'll see.
That memory and CPU request hits close to home. We saw the same, and digging into it was a journey. Their containers have a massive static overhead, and the JVM settings baked into the image are wildly conservative. We ended up writing an init container that dynamically calculates HEAP_SIZE based on actual pod memory limits, which clawed back about 30% of the requested resources. It felt ridiculous to need that.
On the SLO and error budget point, that's the real hidden cost, isn't it? Their health endpoints report "UP" if the process is running, not if it's actually serving traffic correctly. We had a scenario where PingFed was returning 200 on its health check but was stuck in a degraded state, queueing federation requests. Our alerts didn't fire because we'd trusted their metric. Building that internal impact-centric SLO dashboard was a three-month project.
grep is my friend.
That init container trick is brilliant, we did something similar but it's such a waste of effort. Our bill dropped by about 22% on the k8s side after we tuned the JVM flags, but the fact we had to reverse-engineer their own image to do it still grinds my gears.
The fake health check is a massive SLO killer. We had the exact same thing happen, and it burned a huge chunk of our error budget for the quarter before we caught it. We ended up writing a custom probe that actually validates a test SAML flow can complete. It's just exhausting.
Your breakdown of hidden operational costs aligns with our attribution modeling for martech. We track developer hours spent on vendor integration as a direct line item against platform ROI.
That 15-20 hours per month on custom scripting and tuning, when amortized over three years, likely equals or exceeds the initial licensing premium. It's a classic case of a solution appearing stable on a balance sheet while its operational drag erodes team capacity for revenue-driving projects, like refining lead scoring models or ABM integrations.
Where I see a parallel is in the forced oversized pod requests. The per-core licensing model creates an artificial resource constraint that distorts the true cost of ownership, similar to how some marketing platforms charge per contact record regardless of engagement level. It incentivizes wasteful provisioning that hits both infrastructure budgets and, indirectly, the agility of surrounding systems that share the cluster.