How Uno.ai Unified Observability Across Three Clouds and Cut Costs from Day One with OpenObserve

About Uno.ai

Uno.ai is an AI-native agentic platform for GRC, third-party risk, business continuity, and enterprise risk. The company serves large enterprises, including the Global 2000, across many of the regulated markets in the United States.

The team, led by CEO and co-founder Shashank Tiwari, has spent decades building distributed and real-time systems in Silicon Valley, and that background shaped how the company treated observability from the start.

We had observability, metrics collection, failover, and related infrastructure elements baked in from day zero. That was not compromisable, just because of the kind of business we're in and the kind of customers we serve.

Shashank Tiwari, CEO & Co-founder, Uno.ai

The Challenge: Rising Bills for Baseline Monitoring

Observability is tied directly to revenue at Uno.ai. Customer SLAs depend on availability, and missing them carries cost ramifications and potential fines. Understanding service reliability is part of the business, not just good engineering hygiene.

Like many cloud-native teams, Uno.ai started with what came bundled with its cloud providers. The company began deep in GCP, later moved to AWS, and today runs across GCP, AWS, and Azure. At each stage the team switched on the native tooling, including CloudWatch, Azure logging, and GCP metrics and logging, so it could stay focused on building its own product.

The first warning sign was financial.

Our biggest issue, at least the first thing that caught our attention, was that the bills were just rising disproportionately. When we started drilling down, the key learning was that we weren't getting any special value. They were essentially doing what I would call baseline monitoring: collecting metrics, letting us search them, letting us run some essential dashboards and charts. That's table stakes for every observability tool. But the costs were disproportionately high.

The team considered building in-house, assembling an open source stack, and switching vendors. They evaluated practically everything, including Datadog and a self-assembled OpenTelemetry stack, before arriving at OpenObserve.

Why OpenObserve

Tiwari is candid that the first thing that won Uno.ai over was not a feature. It was the people behind the product.

As a technology-first team, we like to work with teams that are also technology-first. We can discuss things where we can tune for our own workload and optimize. Not only do we take advantage of the product, but it helps us scale and design it properly in a collaborative manner. That's very hard with some of the more established tools, because you can't even get hold of the people who designed or architected them.

Beyond the working relationship, OpenObserve's design principles matched how Uno.ai believes an observability tool should be built. Tiwari points out that larger platforms have a perverse incentive to keep data volume high, since more events and more storage mean more revenue for the vendor. OpenObserve takes the opposite approach, compressing data and optimizing storage inside the stack so customers stop paying for sprawl they never use.

The engineering-first tooling sealed it. Queries are easy to write, integrations cover a wide range of sources, and dashboards can be shaped quickly. Engineers drop in SDKs, call APIs, and manage configuration themselves.

I would even give the engineering culture some weightage, because it makes it easier for us to collaborate with a company like OpenObserve.

The Migration: Standards-Based Instrumentation Pays Off

Uno.ai's workloads are demanding to observe. As an AI agentic business, its traffic spikes sharply and then goes quiet, so much of the stack is ephemeral by design. Containerized workloads spin up, finish a job, and disappear, spanning function-based computing, short runs, and long-running batch jobs. These run on managed Kubernetes like EKS as well as self-managed clusters in private clouds, and anything that works on AWS has to translate cleanly to a private environment.

From the beginning, the team deliberately avoided proprietary collectors. Even while using cloud-native tooling and later Datadog, Uno.ai instrumented with StatsD and OpenTelemetry so it would never have to re-instrument when switching vendors. That decision made the move to OpenObserve almost trivial.

When we had to move to OpenObserve, honestly, we didn't have to do much work, because OpenObserve was already very aligned with these standards. With OpenTelemetry, you just flip over and change the destination.

The one area the team worried about was the frontend. UI errors, responsiveness, and click-through tracking were spread across Sentry and homegrown JavaScript backends, and Uno.ai wanted everything in one place. The transition turned out to be painless. Using OpenObserve's RUM SDK, engineers added a few lines of JavaScript and a handful of configuration settings, an effort Tiwari compares to integrating Google Analytics. No one outside the engineering team needed to be involved, and client-side reliability and error metrics began flowing into OpenObserve alongside backend telemetry.

For our kind of stack and our kind of choices, which may actually be common across Silicon Valley, it was easy to migrate. It was not difficult.

The Results

The change Uno.ai felt first was agility. The team no longer sinks engineering time into managing its observability infrastructure. Dashboards, analytics, and queries for usage metrics, AI workloads, and service reliability are configured quickly by the engineers who need them, without becoming an organizational project.

The change that matters most to the business is cost.

Observability stacks are not only expensive, they're increasingly becoming more expensive. The costs only seem to be skyrocketing, and they're proportional to your growth. In a way it's a double-edged sword: you want to grow, you want more observability, but your observability bills grow with it. That's something OpenObserve solves quite effectively by keeping the footprint and the entire cost contained. For a company like ours, that's fantastic. We just love that.

Backend metrics from three clouds, ephemeral Kubernetes and function-based workloads, and frontend RUM data are now consolidated in one platform.

Advice for Other Engineering Teams

Asked what he would tell another engineering team considering OpenObserve, Tiwari keeps it simple: start using it.

It's an open source product. If you feel brave enough, as many tech teams are, go ahead, download it, play with it. You don't even have to ask for permission. And if you want to quickly run your workloads, talk to the team. Drop them a note, ping them on Slack. Given how they operate, they'll come back to you with something workable, and then you try before you buy. You don't have to call a sales engineer, ask for pricing, and wait a week for a quote. Just message away.

Ready to see what OpenObserve can do for your stack? Get a demo or try OpenObserve Cloud for free.