The 53-point gap: AI Adoption Has Outpaced Trust

WILL ROBERTS: Guys, thank you so much to everyone who's joining us for this webinar where we are going to talk about the observability imperative. Uh it's based off of a survey report that we'll go into some extraordinary depth on and I uh will eventually get to the place where I can turn it over to my experts. But first, I want to go through some logistics. Um the conversation that we're having here is recorded and slides will be available afterwards for anyone to download. Please feel free if you're an attendee to ask questions in the chat. Um and if I or another ground cover person and there should be a couple uh don't get to answering those questions in the chat then we'll try and read out the questions in the Q&A section. Uh so please make sure that you also take time to click into the resources uh that are available in the livtorm app. But let's start talking about why we're here. So in April in 2026 we uh partnered with atomic research to survey 500 leaders and individual contributors in the observability space. They shared insights that revealed what trends are showing up in their observability platforms and in the market. Uh as the market tries to catch up with the everinccreasing speed that developers are forced to move with uh their patterns of adoption within this expansion of AI driving that speed have revealed three critical themes. themes of trust, three themes of expense and uh one of a future vision for the role that observability will serve. So first trust what we saw um teams see the value of adopting AI uh within observability specifically and uh that's really only when they're able to trust it which they don't really feel that they can. So we'll go ahead and explain why. Second, a theme of expense. The teams surveyed now call uh observability data strategic and yet it's exactly the signal that they are being forced to cut and we'll explain just how much. And then third for the future uh telemetry has been promoted. It got a promotion and no one told it. Um, it it's no longer an after the-act and debugging backs stop. Uh, it's now a strategic and forward-looking input, which I think some of that a lot of this audience probably could have seen coming, certainly if you guys hadn't read the actual report itself. So, let's start. Let's look at the themes. Trust, what does it mean? How do we come to it? We kind of came to it based off of these numbers. In the report, 87% of respondents said that uh AI or automation is integrated into their observability workflows, but 34%, a far smaller percentage, say that that integration is fully operational and trusted. That's the 53 point gap, the name of the show. That's why we're here. So, Chris P, uh I want to I want to bring you in early here. Um tell me a little bit about what you see in that gap uh the the space between trust and adoption.
CHRIS PRIMEBERGER: Therein lies the mystery right William that's it is that gap in between the numbers and this is um I think the same thing if we would have taken this survey 20 years ago when the cloud was just beginning we may have seen something similar to this where there's a rush to adoption of new tech thinking it's going to solve problems right away and um and cut costs right away and be the savior for for everything. I think if we would have seen the adoption of cloud of course it took over 10 maybe 12 years for cloud to become really embedded in uh enterprise probably longer than that there's still companies that are still testing testing cloud but you know um I think we would have seen the uh the early cloud apps and the cloud devices and everything get uh very high usage early on and then the trustworthiness of it starting low and then growing and I think if you were to take this survey or similar survey now to users of cloud uh you'll see not a gap at all like that. It would be a much smaller if not no gap at all between usefulness and the trust of it. It just takes time and it takes reps and it takes uh day overday business and production. Um so this is not surprising at all to have it have this involving um AI and observability uh early on and uh the amazing thing is that AI is so easy to deploy and use in so many different ways. that the trust part is far behind and we're not catching up to it. In fact, AI is in many ways not trusted at all. I don't trust it very much at all for for certain things. I'm looking at a video on social media. I don't know if that's real or not, you know. I I have no idea. In fact, um I'm taking a a seminar myself on how to identify deep fakes because I need to as a journalist, I'm always looking for truth and I need to before I republish or write on report on something, I need to know that it's real. But in any case, um this uh this number does not surprise me at all. And we can talk about it. Maybe do you think William you think it's worth it just to give a quick um u definition of observability just in case some of our watchers don't know about it or you think it's pretty well known enough?
WILL ROBERTS: Well, it's a pretty mature space. Um which is why I think that the space that we see here uh the gap that we see here is a little surprising. Um because observability is so crowded developed um and you would have imagined that minutesautomation built within it would as a result start to gain or share some of the trust that people already have in uh observability's value generally. But ultimately that's the thesis that we're trying to get to here too right so that it's a good good thing for you to point out right uh observability from our point of view it's the metric slots and traces just to recap um that have become sort of standard to the space uh for your applications for your infrastructure for your AI workloads um and those are really the core uh um inputs that you use to create insights about the stability and reliability of your platforms uh and the applications that you host on them. So important for us to to look at that topic again, take a step back and look at the topic and sort of delay exactly what we're talking about. But within it, you know, there's ample space for automation and and artificial intelligence to help the teams who have to think about that every single day. Um, Chris B, if I could just maybe turn to to Chris Churillo, the the VP of marketing here. And I'm realizing now that I didn't even set time aside for us to go through proper intro. So, just to quickly bring up the the crowd who's here. Uh, Chris Primeberger, veteran analyst and writer in the space. Chris Churillo, VP of marketing at ground cover, industry veteran in uh, technology from data all the way through to observability. Sorry to be so brief about it, but Chris Trilla, if I could throw it over to you for one second. Uh do you see it the same way as uh our friend other Chris Chris Primeberger that it's a question of uh timing in the story of adoption and trust or is there something else that you sort of saw in this in these metrics that pointed to a different question of uh or possible reason of of why people don't feel that trust inherently?
CHRIS CHURILLO: I think there's a couple of things that we have to keep in mind. Um so I think the first thing is um look AI makes us uncomfortable as human beings so we are naturally going to not trust this thing because we feel threatened by it right that's just how we are and that's how we reacted in you know 2023 after the uh beta of chat GP4 came out it all exploded right and nobody believed that this was going to work and like how many doomsday articles did we see right about oh my god developers will no longer have jobs designers are like obsol Um and so there's a natural skepticism that's going to come uh with AI as we go through this journey. Uh but the the interesting thing is that the um the reasons behind that skepticism actually has been changing. Um and so I would argue that in 2023 it was um you know the outputs were okay. They weren't great, right? We could all tell that it was AI. And then uh a few you know I should say just a few months later then like we started to really see like hallucinations were ridiculous. Um and and then um you know over time we started to realize that oh you know this thing is actually missing context and once we give it context then we started to see that hey actually you know it's starting to do a little bit better job right and you know so I think this is going to like constantly evolve. we're going to like constantly like make improvements and then we'll find like you know the next thing uh that we think we need to uh address to overcome our skepticism but and then you know to the point about like in the observability space you know it being just logs traces metrics events I would actually argue that uh that that's that data set was and is continue to be really important for you know our systems how uh the service you know trying to understand the latency between like a couple of services or trying to understand the memory consumption of whatever a database or you know Kubernetes pod etc. Those things you know are are well understood and we've been collecting it for a long time but our evolution also included different kinds of observability data that we've been starting to collect because we're starting to realize that there's even more things that we have to observe in order to fix. Right? is if we look at observability data today, it includes or it has to include tool calls that you know your agents are calling, how long that's taking, how many of them are there, what are the prompts and responses that you know you're actually giving to the different LLMs. You also need to know like which models and which version because like these improvements to these models are like changing every like I can't even say every day anymore. It's like every minute it seems like. Uh and then you know we have this new problem of token usage you know and and how do you count that uh inputs and output tokens are you know are have you know different values and it can have a really severe impact to a business and I think the final thing that a lot of people are starting to get to is how do you now observe whether the outputs were correct? What is correctness? Right? is correctness like back to you know what I said about hallucinations making sure that you know oh this is accurate or is correctness um that it wasn't rude or was correctness that it understood like a policy that you know should have been also embedded into the uh answer there's like a a ton of ways that we can define correctness given like what the application is hoping that these you know agent workflows are are helping them to achieve and we now need to observe all these things because it's not just about latency between a database and an API call. It's now everyone has these native agents in their application. So now the the um the task of ensuring that things are right has increased severely and so it's all of a sudden a lot more data that we have to collect in order to really understand these systems.
WILL ROBERTS: So the scope of observability has dramatically increased in recent years. Um and do you think it's the scale of that data or something inherent to that scale of the data that's driving um viewer or users customers looking at the AI built on that data and uh not trusting what it is that they are seeing.
CHRIS CHURILLO: I think there's two things that are happening. I think one is on that AI layer. Uh so now it's different kinds of data that we have to collect so we can understand that. I think there's another layer that's happening at the same time and that's you know if you think about who was using observability data before all this AI stuff really happened you know it was just it was us right we would like we would get a page we'd look at the ticket we're like okay now we got to go and observe and see like who's minutescausing all this like problem and then uh you know we triage it uh which was you know you know hap always happened in the middle of the night and then we'd look at other data sources to ensure that we understood the triage. It wasn't just the observability data. It might have been like you have to look at the ticket. You might have to look at like other documents that might explain how systems were put together. You know, what are the workflows? So, we had to look at lots of different places to really make sure that we can understand and triage these things. And what's interesting is like we you know because of cost pressures a lot of times we sampled a lot of the observability data because like you know I only need if I have like a you know a 500 error do I really need all 5,000 instances in the last hour right I could probably get away with sampling a lot of that because I know I'm I'm a human I'm used to this. Um, but the other thing that's been happening is we're now actually asking agents or starting to build agents that are gonna start doing that job for us. And so, you know, and agents need that context, right? Or they're going to hallucinate. And the last thing you want to do is have these agents that are trying to triage something that's going to be missing a lot of this uh uh data. So, now we have to rethink our, you know, sampling um strategies that we had in place previously. And oftentimes that means that we're going to have to like stop oversampling uh so that we can give these agents a lot more context. So there's I feel like there's a couple of different angles where it's pointing very clearly why this trust or lack of trust is there because I think people are starting to realize this data problem is um you know a lot bigger than we realize. But on the flip side I think well I think people are excited about these possibilities. So, they're also willing to like dig into it and understand it. So, it's it's not I don't feel like it's more like, oh, we're completely skeptical. We're worried it's going to take over my job. I think it's more now in this, yeah, we have this problem, but I'm willing to now dig into it and learn about it.
WILL ROBERTS: Chris, does that ring true to you, Chrisberger?
CHRIS PRIMEBERGER: Um, well, Chris Trillo knows more about this than I do, but um well, I mean, it's it's your business. Um, so I I look at it from a slightly different standpoint. Um, we've always had more data than we expected. It seems like there's always more data out there. How do you account for it? How do you uh trust it? Um, how do you store it? That's where I come in. Um, you know, data has to has to live somewhere. All data and it's in storage. That's that's where I started at eweek is the storage reporter years ago and it turned into a cloudbe right away in 2006 with um S3 when that was released by um AWS and the data thing has been so so huge and so I think uncontrollable data in my opinion is almost uncontrollable. We think we can control it, but there's always new data, you know, and how do we account for it? How do we use it to help our businesses? That's what the challenge is for it. Um, I just wrote a piece a week ago or so in uh the new stack about token maxing and you know when AI came big to the party a few years ago, um, companies in general wanted to use as much AI as they could in everything. not knowing exactly where that direction was was headed. They just wanted to use it and check it out and they didn't care what the costs were. Well, that is starting to back up on them because the cost, it turns out using too many tokens in AI is expensive, very expensive. And when the uh the uh bill bill bill collector comes uh a lot of companies are surprised again data going crazy with data and using too many tokens it's all part of the same picture controlling a company's information keeping it safe and secure and making it available whenever uh an employee needs it. Now that how does that relate to our our our discussion today? Well, it's all about the same topic. We're all talking about data and data insights. Um, and I I think Chris is looking at it from a developer standpoint, which is way to do it. I'm looking at it from a business standpoint. And it looks like um uh the token maxing party is over right now. That's what my headline said in the new stack. Um because there's a couple of companies that are really taking taking charge of that and trying to control it. But um I just don't think our data can be controlled very well. Even with all the good tech we have today, I just don't think we uh are there yet or like we were 20 years ago with cloud. We weren't there at the very beginning of cloud. Right now with AI, it's everything's exploding in so many different directions. Now there's so like Chris said, there's so much so much more data and there's so many more layers that we have to deal with now. It gets very complicated.
WILL ROBERTS: Well, It certainly is an interesting moment of data scale, right?
CHRIS PRIMEBERGER: Yeah. Well, exactly. And if we can't automate much of this and trust that automation, we're we're in deep dudu.
WILL ROBERTS: Well, to call out the other stat here, we talked about the the 53 point gap and the space between it.
CHRIS PRIMEBERGER: Yeah. Um the what what's pretty clear is that it does seem like it's a data problem maybe in a slightly different framing as we've been discussing it so far. Um if we look at this the stats only 22% of the respondents felt very confident that they were getting enough high fidelity signal. Yeah.
WILL ROBERTS: Um, how do we how do you how do you define high fidelity signal? Just it's and Chris, I'm sorry. I'm getting a little bit of an echo on my side. I don't know if Chris truly, you can hear that as well. Yes, I can. I can. No, you're okay. Um um high fidelity signal being the uh uh high fidelity signal being the kinds of quality data that you need to actually uh debug or Okay. Oh, sorry Chris. I'm still getting pretty significant feedback. I'm gonna I'm gonna mute you for a second. Um, sorry Chris, I just was getting super super loud feedback. So, I'll unmute you in a second. Uh, I think I I can ask you to unmute. Um, yeah. So,
WILL ROBERTS: high fidelity signal. Uh, the the point of that is that it's uh data rich enough for teams to use it for debug or for tracing issues throughout their platform or throughout their uh applications. So it's really important um it's an important measure of quality right that's essentially a measure of quality and when it relates to AI issues in particular that's an important thing for us right we want to make sure that we have sufficient quality data so we were talking about the overwhelming story the story of overwhelming data for IT teams that's totally a a reasonable uh problem to you know think about especially in historical context What we see is that there are actually very few members of this uh survey group who felt that they had uh felt very confident that they had enough of that high high fidelity data to do the kinds of um uh uh critical tracking that they are tasked with on a day-to-day basis as a part of the platform teams.
CHRIS PRIMEBERGER: Okay, gotcha.
CHRIS PRIMEBERGER: So okay, so that so is that mean that that's edited data that's already been through an uh an editing cycle?
CHRIS CHURILLO: Uh yeah, typically you don't want to edit um uh observability data, right? Because it's a if you think about it, it should be a record in time of what happened, right? So it should be immutable. Now sometimes uh you know data comes in late or you know sometimes you do have to make like some small changes to it but theoretically you shouldn't be because it's supposed to represent like what that failure was so then you can go back and you know you know try to fix it.
WILL ROBERTS: All right. Yep. That's right. and um you know very confident in this survey was the highest measure of confidence that their data was sufficiently rich for them to be able to fix the problems that they were seeing. Uh I'm just going to add in that only 50% are confident at all that they have sufficiently rich data. So a measure low measure or the combination of this and a measure lower in terms of their overall confidence scores um uh as the com the combined group 50% are willing to say that they feel like they can trace um problems throughout their infrastructure at all. So you're right that there there might be an overwhelming flow of data Chris Primeberger in the in the IT world but the developers who are trying to keep applications and their ecosystems alive and healthy don't know if they're observing sufficient uh uh volumes for volumes of of high quality data for their purposes. So there in lies the rub.
WILL ROBERTS: There in lies the rub. I think that we've talked a lot about trust and the importance here of finding the right quality of data for teams to uh actually be able to confidently look at their observability platforms and say that they can fix an issue. Um I think that there's an important paradigm to keep in mind here which is that uh there is so much data as you and as both Chrises have have spoken about. Um finding out what data is important to trust is often a decision that these observability teams don't get to make for themselves. Uh they're sort of forced to go through this sampling ex uh exercise.
WILL ROBERTS: Um and that's going to lead us to our our next theme that we observe throughout the platform because they are forced by virtue of expense. The the observability teams, platform teams, engineers who responded to our observability survey felt uh that there were a lot of overlapping patterns of cost that were um impacting how they thought about observability. And it's it's probably not surprising to hear that a survey from teams on observability uncovered expenses as a key theme. Uh it's often seen as a cost driver and that sometimes causes some aida some anxiety. Um it's probably also not surprising though that they're investing in the capabilities to observe their AI workloads. Right? So uh let's talk a little bit about even despite the fact that cost is um often a top thought it's still a observability for AI is still a piece that teams are investing in heavily um off the top 50% of organizations or thereabout uh say that they are spending to the tune of 26 to 50% of their observability spend already on AI workloads. Yeah.
WILL ROBERTS: Um, and 61% of the respondents say that they spend at least a million dollars a year on observability for our survey responses.
WILL ROBERTS: Those are kind of eye watering numbers. Yeah.
WILL ROBERTS: And the breakdown of the paper brings us in brings you as a reader into some more depth for each of those uh with different segments and slightly different spins. But I I do I want to pass it off to Chris uh Turillo this time first. Um do those numbers surprise you? Uh you spend a lot of time focusing on the market as a marketing leader and having been in the space um for sufficient time to have acred expertise. Do you see that companies are uh does this feel like it's commensurate with where you think companies are in terms of early or late in terms of their adoption of observing AI? Like how does this sort of read to you?
CHRIS CHURILLO: I mean it doesn't even have to do with AI. Uh just if you think about the data you need to collect, you know, for your systems if you just think about the characteristics of observability data, there's three characteristics that will easily contribute to a ton of data and expense. The first characteristic is like high cardality. So you know unique values that you need to have. Maybe it's a user ID or a session ID. These are sometimes you need that information to be able to troubleshoot what's actually happening, right? Um high dimensionality. Sometimes you have to have all this metadata around your observability that can explain things like uh deployment uh version or a region or maybe a specific hardware. there's this other information that gives context about you know um the trace um because maybe it's only happening on this particular server etc. And then the the third thing is just that to just add on to get that complete context right in traditional systems we're talking about payload you know all the little details like what did you actually send in that request to the database you know was it customer's credit card their name like what is it that you send that could have caused you know that error and this is just in traditional observability having all that information it just adds up and that's why you know was naturally going to get like very very expensive and that's why we all felt the need to sample. Um, and it just gets worse with AI data because like context now uh it's not the payload is now the the um the uh the prompt and the response, right? That has a ton of information in there potentially. And then as mentioned before, right, there's also like you know the token usage. It's it's kind of ironic, right? So we're we're collecting data about token usage so that we can then like save on expense. But you got to collect that data to be able to see that. I mean the whole thing is actually very ironic because we we we've been you know we've been sampling it so we can save money but you collect that data so that you can get visibility so you can debug something that might actually cause failures that might cost you a lot of money. I mean there's such irony in this whole thing right? Uh it's supposed to save you, but you can't you're not allowed to collect it because you're getting in trouble because it's too expensive.
WILL ROBERTS: Yep. Uh Chris P, do you look at that 61% of um respondents and think that that makes sense or does that seem like that's a surprising amount for, you know, 20 early 2026?
CHRIS PRIMEBERGER: It's Yeah, it's a little surprising to me that it's that high, but um maybe it shouldn't be. But you know uh I would bet five years ago uh even that that would be next to nothing. It's it's only been the last few few meaning three years that that is uh starting to climb like that. Um and it's it's early and so it's going to continue to um to go up. I think uh uh I was looking at some what what some of these tools cost um just a couple years ago um observability tools anywhere from free of course open- source uh point solutions to over 50,000 a month. Well, it's gone way beyond that according to this. So, it's it's incredibly rising incredibly fast just like the use of AI. It just it parallels it completely. And um I think that's you know actually the industry benchmarks I I found a a note that says industry benchmark suggest that observability spend should ideally sit around five to 15% of total infrastructure cost. I think this is way past that. How does that bode for the future? I don't know. But it's like tokenization. uh companies were going crazy buying tokens and using them in their production and now they're cutting way back all of a sudden. Not all of a sudden but the last year or so they're cutting way back. They're realizing how expensive it is. Um 61% it's going to it's going to go up a little bit before it goes back down I think for sure.
WILL ROBERTS: Well the survey showed that teams are already responding. They're looking for ways to naturally respond to those cost pressures um in pretty predictable ways. Uh sampling, renegotiating contracts, exploring things like open- source alternatives to their established vendors. Um, I think that we could have predicted that was going to happen in the observability space as these bills have grown large and the workloads are uh getting increasingly complex and going to drive those large workloads further up. Yeah. Um Chrissy, do you see any surprising scale in the response statistic there of nearly 80% of teams that are trying to adjust to these cost pressures or uh is that not surprising to you?
CHRIS CHURILLO: It's not surprising at all. I mean like just ask any developer about what their retention policy is, right? if if they could, they'd love to have, you know, I don't know, some crazy six month, one year retention policy, but it's like 30 days, 14 days. We've been doing this for, you know, for quite some time. I think we just haven't been really honest with ourselves about, you know, what what would be ideal if we could collect it all. Um, and you know, we weren't really hurt by it, but I think um, we we might start to be hurt by it because of, you know, trying to introduce these AI agents that that might need a little bit more of that context.
WILL ROBERTS: Yeah. Well, the agentic layer is hungry for context. That is to be sure. And if you don't give it to it, you run into the stats that we saw before that 53 point gap where people have deployed AI because it's Chris uh P to your point, Chris Primeberger to your point, it's easy to deploy. Um but if it doesn't have the right context, you burn that trust so quickly uh so immediately. And clearly the development the developer engineering teams that are um trying to harness that power of potential power of artificial intelligence are feeling burned on both ends. They can't trust the AI, but they also can't sample or they're being forced to sample and can't retain the kinds of data that they need in order to get to a place where they actually could trust the outcomes and have it drive fully functional automation with their observability data. entirely predictable that um a cost pressure like this where increasing costs are inevitable uh was going to burn the the trust capital that um we are trying to build into our AI and agentic solutions. So I think that the the 53 point gap is starting to take some more color here as to how how and why we got to this stage. Absolutely.
WILL ROBERTS: I think that one of the uh interesting things though is that there is still inherent in the the data the survey data that we saw um a future vision a story of where observability data is pushing the users and the leaders who we surveyed. Um there's an opportunity obviously to close that 53 point gap between trust and adoption. Um, and I think that that's important because when you look at how teams want to use this data, it's for forward-looking decision-making. I mean, 90% of respondents, nearly 90% of respondents uh from these the firms and these individual contributors see it as a key pillar for forward-looking decision-m and prioritizing. Um com if you compare that with uh the reality that they are also for the most part being told to cut back on observability data that seems like a vision which will be hard to realize. Um Chris P I'm wondering if you see any narratives uh that parallel this from your experience or that you have any more data to support that idea that observability is uh an important input for decision-m for the future.
CHRIS PRIMEBERGER: Of course it is. And um and it's important for decision making not only by humans but by agents agents too which are going to be making more and more decisions uh in production as we go along. Uh we need to trust those agents and there's still a trust gap I think there also. I don't think uh a lot of those are mature enough to be used on a daily basis. They are being used in many cases, but there's still hallucinations. There's still errors that get into these systems and cause problems. And um I I think these things all kind of tend to work themselves out in time has been my experience. Um starting with some of the I mean I could cite the examples that I mentioned before of the cloud and other and mobile and and other things that those new techs come in we use them some some work some don't the uh companies you know winnow themselves out over time for the winners and losers and um it's just a matter of placing our bets uh on systems that we maybe have used in the p or companies we've used in the past and uh continuing to stay with them going forward. I hear what you're saying. You know, I mean that's what it is and humans make those decisions but lots of small and other decisions are made by automatons down the line.
WILL ROBERTS: Well, the snowball effect of systems down the line depending on that data is also pretty obvious from the stats. Nearly 15% nearly 50%, excuse me, of the respondents are connecting their telemetry data to external systems or to some sort of uh agentic layer on top. And that's pretty critical because uh that moves your observability stack from being something that you simply for um uh a retrospective and all of a sudden it if it goes out your production systems are going to get impacted and so a fivem minute outage from your observability data or your observability vendor becomes a sort of knot in the hose of those downstream applications. you're not getting the the water that you need. Um Chris, does the role of telemetry data Chris C that is does the role of telemetry data in downstream systems seem like a natural end result to you too?
CHRIS CHURILLO: Um I mean we've all seen the cursor codeex you know name your favorite tool um you know write code on behalf of an engineer um and then they're like oh yeah I'm going to open up a issue a PR in GitHub and then we're going to push it through. We've we've all seen that, right? And then some developers have actually gone fully uh you know using all agents to write code and they're not writing code themselves. Uh but in order to do it um uh in a very safe way, you do need some of that. You need context from telemetry data, you need context from ticketing systems, you need context from a bunch of different places that is going to explain like what's going on, right? because I could I could um I could try I could build something and all of a sudden I have my my query is going like wonky. I don't understand why and then it could be so bad that you know maybe that query is then triggering retries that's going to trigger like a ton of token usage. So it could become really really painful. But if you didn't know that the uh index in a database was like deleted you wouldn't know to uh potentially avoid those kinds of things. So I don't think it's just telemetry data. I think it's all the data that surrounds a developer and being able to write code to understand their systems to understand like what's just about to happen. What did someone else do? But I do think telemetry data is like one of the key uh important data sources you know for those kinds of workflows.
WILL ROBERTS: Yeah, well said. Well, the uh summarization from these key themes is interesting as we sort of break it out by the story of company size and also what it means for our audience, right? Um when you look at this data and want to know the answers to the question of uh what it means for you um whether you're ahead or behind, it kind of depends what segment you fall into, right? uh and who it is that you want to compete with. It's important for people to remember that um the folks that might be playing in your current stage might not actually be uh the exact set of people that you want to be competing with. You want to try and move up market and take market share from other folks. So like what are they doing um that you need to try and match too? Um well uh in this we saw that in the early stage uh only 22% of respondents said that they enjoy comprehensive observability which is comprehensive observability is the highest measure of minutesconfidence that users express um when talking about their observability. And uh it's specifically confidence that their tools capture sufficient highfidelity data to come back to that term crisp uh when it comes to detecting real AI issues. So this group, a very small subset of early stage companies feel confident that their observability vendors are um enabling them to get to a place to truly detect real AI issues which is fascinating. uh as a subset of this by the way only 21% would claim that their endtoend uh observability and the visibility into that endto-end observability is excellent um which full visibility across your AI systems is another measure of competence which is important and not a stat on on screen but still an interesting talking point. Um I think that it's pretty obvious to a lot of us that those a early stage companies that are scaling the organizations uh would benefit from quickly establishing their own personal ROI um on how their observability impacts their organization and commit to it before they try to aggressively scale their observability. They have to kind of decide like what is mission critical if they're going to effectively compete against the mid-market set of respondents who say that they are fairly confident a higher there's a higher rating of competence 26% would say that they enjoy the highest rating of comprehensive observability when they were asked how confident that their observability platforms actually capture that sufficient high high fidelity data. Um but that mid-market group is also interesting because a fairly large nearly a fifth of them uh for a segment are considering consolidating their tooling, right? They're looking at their tooling and saying that they have to implement adaptive sampling in some way or telemetry tiering. Um and they're considering as a larger group adding more sampling in this coming year. So clearly there's this gap, right? 26% of these folks feel that highest level of competence. Um and so few of them uh feel like they can uh confidently diagnose the issues without having to introduce more and more sampling in their sort of observability stack, their telemetry data. And that that's interesting especially when you look at who they're competing against or trying to compete against in the enterprise. I think at one point Chris Primeberger you were talking about looking at the established players and who it is that we can trust. Well that's a a very confident group here. Uh 60 65% of respondents in this category say that the average time that it takes to detect and then resolve AI application incidents is at most a day. um 28% detected related incidents within minutes and resolved within the hour and then 37% of them detected within hours and then resolved within the day. So when it comes to observability the uh enterprise group has substantial confidence uh that they've deployed it in sufficient um width and depth that they are going to be able to resolve incidents quickly. And if you are a mid-market or an early stage company that's trying to compete against that enterprise, that's an important thing for you to remember. Um it's reliability is a differentiating factor for them, right? Uh it's the bar that you have to meet and they are uh raising that bar all the time. They're also weaving AIdriven automation and recommendations into their platforms. nearly 3 37% of them are adapting excuse me adopting AI workloads into their observability platforms and it's a really uh hard um and cumbersome effort for those startups and and mid-market groups to try and catch up because they are moving with speed too uh the enterprise group is so what do you do what are the takeaways how do we get you caught up with the enterprise If you're a part of that group, well, the playbook is kind of clear actually. Um, you have to eliminate your blind spots. And the reality is that you should be able to pick which are the blind spots that you're okay with, right? Don't let your observability bills um or the fear of a spike dictate that choice for you. We know that not every uh data point is critical, but you should be the one that's deciding what blind spots you're okay with. Second, measure what matters. Like I said, not every data point matters. Um not everyone is a signal. And after you've observed something long enough, you can make that choice about what it is that matters uh and measure that thing. Um, there's a trend across the space across the space. And Chris, I'm so sorry. I'm gonna back real quick because I'm getting an echo again. Okay. Um, all good. Uh, the trend across the space is that we've seen that I I think is important for our folks trying to catch the enterprise uh to be aware of which is um consolidation, right? minutesget out of that sort of swivel chair crisis management experience if you're in the startup and um mid-market group because it is it is going to be a detractor for you ultimately when it comes to resolving incidents if you're switching from one place to the next uh and trying to keep your applications and systems healthy. Fourth, design for AI systems. They're going to be your connective tissue. um that might be a differentiator for you and uh your agents or someone else's agents might be a customer in the future. Um design your observability stack for that and that reality. Uh fifth, embrace open telemetry. I think that that's a pretty obvious recommendation for a lot of folks here, but just to talk about it, it's as a standard, it will support uh in the future the investments that you make now, especially as you start to scale your AI systems. And then finally, connect your architecture to your costs and to your controls, but don't let your architecture be dictated by them. uh or don't let your investments in the data for your infrastructure be dictated by them. Your observability doesn't have to be forever handcuffed to some SAS platform. Uh you can control your architecture in your own ways.
WILL ROBERTS: And that's it. Um I'm so appreciative of Chris uh Churillo and Chris Primeberger. You guys both joining. Uh, first I want to offer my thanks to you guys for spending some time with us while we while we host this conversation.
WILL ROBERTS: For the people who are viewing this now or in a recording in the future, first things first, make sure you scan the QR code to download your copy of the report. And while you're doing that, if for some reason you ended up here and you don't know about ground cover, you should know. Uh, but let me just tell you quickly about us.
WILL ROBERTS: We're a BYOC first full stack observability platform. Um that's in contrast to SAS observability and the deployment model allows ground cover customers to keep their sensitive data and high volume telemetry data in their own clouds. That means that they don't have to worry about paying for hosting fees and compliance concerns. Um and their compliance risks just dramatically decrease with that model. Also, as a result, our customers can keep up to 10 times the data volumes that they would as compared to a SAS observability platform and it's far more secure. If you want to experience it on our data, try the playground at play.gggroundcover.com. If you don't understand how this kind of observability would fit into your ecosystem, book a conversation with a solutions architect at groundcover.combook- a- demo.
WILL ROBERTS: Um, thanks everyone so much for joining again. Chris and Chris, thank you guys so much for spending the time with me. I really appreciate your guys' time this morning.
CHRIS PRIMEBERGER: Okay. Thanks a lot. Sorry for the echo. No, all good. All good.
WILL ROBERTS: Okay. Bye, guys. Have a good day.