Infinidash: AWS's New Observability Play Has Great Bones and a Terrible Bedside Manner

AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: "CloudWatch Omni" is a wretched name that I will not be using, so for the rest of this article and the foreseeable future I will be referring to it as "AWS Infinidash", which is what they should have called the bloody thing in the first place.

What the Hell Is It?

Infinidash is positioned as being an AI-forward observability implementation for your various applications. I'm excited that the second sentence of their post reads "You reach Omni through a dedicated URL for your organization and sign in with the identities you already manage, so working in Omni does not require access to the AWS Management Console." This is remarkable not so much for what they've done, but for the atypical level of self-awareness this demonstrates; the AWS console is a dumpster fire of sadness and regret. Every attempt they've made to fix this only serves to make the experience more uneven, sending it deeper into the territory of "you must prove yourself worthy to achieve your goal," and the end result comes across as being more than a little condescending to the customer along the way.

We'll come back to that.

It's clear that AWS is very proud of what they've built, with other folks clamoring for credit along the way. Included on their marketing site and the blog post was a testimonial:

"As a design partner for Amazon CloudWatch Omni, we helped shape a single AI-powered observability solution that will give our engineers topology-aware intelligence and natural-language querying across all telemetry from a single surface, with full data ownership through OpenTelemetry."

— Parvez Naqvi, Managing Vice President, Cloud Platform & Resilience Engineering, Capital One

After spending hours navigating the onboarding, I found Capital One’s assertion that it helped design this experience less reassuring than presumably intended, and I am expecting at least one Capital One employee to reach out with a full-throated apology as a result. I would further point out that OpenTelemetry establishes full data ownership in the same way as an HDMI cable establishes ownership of a television station: that is to say, it absolutely does not.

Let's Set It Up

But marketers are going to market, and I have things to do. I kicked the tires on Infinidash, and the setup process was classic "Day 1 of an AWS product launch." The service itself exists outside of the AWS console, but to get this set up you're thrown directly into some of the sharpest edges the AWS console has to offer.

I tried to spin the thing up as an organization domain (whatever that means; the console was remarkably tight-lipped) and the organization-level option was disabled, with text telling me it was only available in AWS Organizations. Trouble is, it's 2026 and I am not wantonly irresponsible; my test account is a member of an AWS Organization. My AI assistant (motto: "Never give up, never surrender!") threw up its virtual hands and said "the hell with it, we can configure this later if we keep it around." I wasn't quite ready to throw it in, so I tested it in another account and found myself hard-blocked: that organization's IAM Identity Center (motto: "It's not IAM, you stupid simple child!") was based in us-east-2 (Ohio), and at launch Infinidash is only available in Virginia, Oregon, and Dublin.

Great job, team.

Once I got the thing configured, it bounced me around to this new "outside the console" experience, and… basically left me there. The fact that I had to spend the next fifteen minutes googling, documentation diving, and cajoling my coding agent around this is a clear sign of an absolute shit-tier onboarding flow. It very clearly suffers from the common problem of "everyone who was involved with launching this thing was so close to the problem that they were blinded by it." It seems that the design brief didn't consider a customer who might not be deeply familiar with observability concepts, Otel, and the various CloudWatch nuances.

I want to give specifics, because I can already hear the indignant emails being drafted: if after a customer onboards they are confronted with a chat box and little else beyond a couple of catch-all setup cards that lead to inscrutable flows, you have screwed the pooch and should probably consider applying to be an FBI agent as a viable career change. Clicking into the ingestion button / flow seems to only accept the idea of routing AWS (or, for some godforsaken reason, Azure) resources of a few very specific types into this. A user with already-instrumented OpenTelemetry in their application will not find a clear existing-collector ingestion path in the service's onboarding, as this is apparently an exotic condition in 2026. Instead I had to go diving into CloudWatch docs to discover what endpoint to target, as well as the delightful fact that while it accepts bearer token auth for metrics and logs this will not work for traces out of what I can only surmise is "sheer spite," insisting instead on SigV4 signing.

Eventually I Got Traces Ingested

I want to thank Codex for its assistance here, while giving absolutely no credit to that aforementioned chat box within the Infinidash console; not only was it supremely unhelpful, but it was also slow as molasses—to the point where I only discovered it had answered a question well after I had worked around the issue, then returned to that browser tab much later.

I'm already a paying Honeycomb customer, and I've been throwing a bunch of traces at them for over a year in an effort to make my infrastructure problems partially their infrastructure problems as well. Now that I had Infinidash hooked up, I started asking my agents to find actual problems in the data sets.

This worked out better than expected. Both products exposed the same corrupted destination-port in my firewall logs. One of my projects had a latency measure that was in fact "how long it took to report the error" instead of being tied to the product that failed. These were instrumentation issues in my applications. Neither product was responsible for the defect, and as expected neither could magically repair them.

Infinidash earned a point above Honeycomb in one specific way: it has access to other CloudWatch items, including my EKS logs. That explained a connection refusal by my AI-powered singing coffee pot that Honeycomb couldn't, because I wasn't shipping all 6.5GB of monthly EKS logs off to them. This is where the integration with the rest of the infrastructure shines.

But finding your way to that kind of answer is in fact part of the product. Honeycomb outclassed this thing in a bunch of ways. Their agent interface exposed named datasets, recent activity, and field schemas. With Infinidash, I had to explicitly instruct my agents to hunt down the product-specific skills needed to make sense of the output. This is damned weird, given that the AWS console itself as well as some services like Lambda lead with "give this prompt to your agent" messaging that sets these things up at the outset.

I also am unimpressed that my agent had to correct examples in the published skills, then discover the structure of its shared telemetry tables. I was able to get to an outcome, but I had to collaborate with my agent around things that Honeycomb has long since taken out of the list of "things I have to care about."

Use Any Agent But Preferably Ours

The key philosophical difference here is one of a product that accommodates my agents versus a product that wants me to use its agent. Infinidash does have APIs that let me do that, but that was very much not surfaced as a golden path. That's a very weird choice for a product that's explicitly positioning itself around AI.

This problem also doesn't end once onboarding is complete. Discovering a new service, understanding its fields, and figuring out where its data lands is a recurring part of operating a system. It’s sold as making these questions easier to answer, but it’s got a learning curve you have to climb every time your infrastructure changes.

My Assessment

Infinidash works. It has useful engineering underneath a crappy user experience, and its access to existing AWS telemetry helped explain an actual application failure. That makes this all the more frustrating, because there's demonstrable value here! Why is it buried under work that I as a customer shouldn't have to do?

AWS is continuing to be comfortable treating the customer's time as an unlimited resource, while companies like Honeycomb are demonstrating that an agent interface can require substantially less customer supervision. Infinidash claims to exist "outside the AWS console" but succeeds in having significant moving parts in the console, while the rest is outside of it. This makes things worse, not better.

Remember, I brought working instrumentation, an existing observability regimen, a couple of AI agents, and (believe it or not) good faith to this exercise. I still got to spend multiple hours bridging gaps that really should have been, if not solved for me, at least explained at the point where I as a customer encountered them.

Moving the interface outside of the AWS console was a golden opportunity to reconsider the relationship with a new or expanding AWS customer. Instead, it came with an all-too-familiar refrain of having to prove yourself worthy, now with an extra browser tab. The customer will learn our terminology, discover our prerequisites, reconcile our documentation, and eventually come to appreciate what we built is just flat out wrong. There are a lot of observability tools out there today; this one doesn't serve its customers nearly as well as a number of truly customer-obsessed competitors do.

I got Infinidash working. AWS should be extremely concerned with just how much work that sentence demanded of me as a customer.