Nymbus Cuts Observability Costs by ~67% While Gaining Deeper Production Visibility with groundcover

About Nymbus

Nymbus is a cloud-native, full-stack banking platform powering community banks and credit unions across the U.S. Founded in 2015, Nymbus modernizes legacy core banking systems and supports both traditional and digital-first institutions through a unified platform spanning core processing, digital banking, onboarding, lending, and analytics.

The platform runs complex, event-driven workflows in highly regulated environments where reliability, performance, and auditability are critical.

Challenge: High-Cardinality Systems at Scale

Nymbus operates a core banking platform for clients, with deep interdependencies across many third-party services. When performance or functional issues occur, the blast radius is wide, and identifying root cause across systems can be complex.

To investigate effectively, the team relies heavily on metrics in addition to logs and traces. They intentionally run metrics at extremely high cardinality because this can proactively identify anomalies and alert the team before a noticeable impact to system performance or functionality occurs.

As the CTO put it,

“Our use of AI at Nymbus has empowered our operations team to analyze much larger data sets from metrics and find anomalies and correlations. We prefer to enable any metric that could be useful, but this can drive significant cost. We needed a solution that was significantly better and more cost-efficient for large metrics volume.”

Prior to groundcover, Nymbus was using a third-party SaaS provider for observability. As the platform scaled, costs became increasingly difficult to control. Even with restrictions on data capture, the annual run rate quickly increased to ~$300K.

This approach worked technically, but it created serious problems operationally:

• Metrics were the largest driver of observability cost
• Traces had to be throttled to stay within budget
• Metrics in non-production environments were routinely cut
• Engineers spent time managing observability spend instead of debugging systems

Even with these compromises, critical context was still missing during incidents. Sampled traces and filtered metrics made it difficult to understand rare performance issues and tail latency in a complex, event-driven system.

Why groundcover?

Cost as an Engineering Constraint, Not a Finance Problem

Nymbus was on track to spend roughly $300k per year on observability. groundcover’s bring-your-own-cloud, node-based pricing reduced that to a flat ~$100k per year, saving ~$200k annually, or roughly a 67% reduction.

The clarity of the cost model made the decision straightforward.

“The cost savings alone made groundcover an easy decision, but the surprising part was that the lower price still covered our full data capture needs and delivered better functionality than our prior solution.”

Now that data volume was no longer a significant driver of cost, the operations team didn’t have to invest time in prioritizing what data to capture and tuning ingestion filters. Instead, they could focus on actual runtime analysis, proactively finding issues, and identifying areas for improvement and optimization.

Metrics-First Observability Without Throttling

Although logs and traces are still a critical component of observability and support, Nymbus relies heavily on metrics to watch the overall health of the full system, including deep inside the runtime of each component. This has proven to be a great early indicator of a problem forming. With groundcover, the team could:

• Keep high-cardinality metrics enabled by default
• Stop filtering signals preemptively
• Avoid building dashboards purely to control spend

This meant engineers could investigate issues using data they already had, instead of discovering too late that a critical signal had been dropped.

Debugging Tail Latency Without Debug Logs

One of the most impactful changes came from groundcover’s eBPF-based runtime visibility, which enabled insights that weren’t available from the prior solution. The team gained greater granularity and deeper visibility into request and response details, along with more control over filtering and drill-downs into trace data. This allowed them to isolate a very small fraction of API requests that were significant performance outliers and identify what was unique in their request and response patterns that was driving the increased latency.

Previously, this was invisible:

• Sampled traces hid rare slow paths
• Database queries were parameterized, masking runtime values
• Debug logging was not an option because it would further degrade performance

With eBPF, engineers could inspect request and response context for only the slow paths, without changing code or amplifying logs, making root-cause analysis practical again.

What It Took to Unlock Deeper Visibility

groundcover’s eBPF sensor required architectural tradeoffs. Because eBPF does not work on Fargate, Nymbus had to begin moving workloads toward EC2-based Kubernetes nodes. This introduced real-world challenges:

• More aggressive container rescheduling
• Temporary workload churn during rebalancing
• Additional tuning required to stabilize auto-provisioned nodes

The team accepted these tradeoffs deliberately, because the debugging capabilities unlocked by eBPF outweighed the operational cost. This transparency mattered. It was a conscious engineering tradeoff, not a free win.

Power vs Risk in a Regulated Environment

Payload-level visibility is extremely powerful for diagnosing rare failures and tail latency issues. In regulated financial systems, it also raises legitimate security and compliance concerns. As the team discussed enabling deeper runtime visibility, the reaction was immediate.

“The groundcover BYOC model lets us capture more detailed data using eBPF, because that data stays within the AWS accounts we own and control. This allowed us to pass our security and compliance reviews and capture this extremely valuable data.”

The concern was not unique to groundcover. Any system capable of capturing full request and response context introduces risk if that data is not tightly controlled.

Running groundcover inside Nymbus’s own cloud made that risk manageable:

• Sensitive data never leaves their infrastructure
• The platform remains within PCI scope
• Access controls can strictly limit who can view raw request data

This balance allowed operations teams to gain deep visibility while keeping security and compliance teams comfortable.

Impact and Results

Production Debugging

• Identification of rare slow requests hidden by sampled tracing
• Faster root-cause analysis without enabling debug logs
• Better understanding of event-driven performance bottlenecks

Cost and Scale

• ~$200K saved annually
• ~67% reduction in observability spend
• Flat pricing that scales with infrastructure, not data volume

Developer Experience

• No need to throttle traces to control spend
• High-cardinality metrics enabled by default
• Observability treated as a core system, not a budget liability

Future Outlook

As Nymbus continues to scale its banking platform and onboard new institutions, the team plans to expand trace coverage and lean further into high-cardinality metrics. With groundcover’s architecture and pricing model, they can increase visibility without reintroducing cost-driven blind spots.

Try it yourself for free

Want to see how teams like Nymbus achieve full observability without unpredictable costs? Try groundcover for free today.