Hello, and welcome to the Elastic Observability Update Metrics call. Today's call is being recorded. At this time, all participants are in a listen-only mode. Following prepared remarks, we will open the call for questions from covering analysts. I would now like to pass the call to Alex Kurtz, Vice President of Investor Relations. Please proceed.
Good morning, everyone, and welcome. I'm Alex Kurtz, Vice President of Investor Relations here at Elastic. Thank you for joining us today for a deep dive into our new metrics offering. Joining me are Baha Azarmi, General Manager of Observability, and Santosh Krishnan, Senior Vice President of Security and Observability Solutions. For today's agenda, Baha will start with a brief presentation, followed by a short customer video, and then we'll open the floor to Q&A. First, let me quickly run through our legal disclaimer. Our presentation today will include forward-looking statements, which may include predictions and expectations regarding the market and demand for our products and solutions, as well as expected capabilities of our products and solutions.
These forward-looking statements are based on factors currently known to us, speak only as of the date of this presentation, are subject to risks and uncertainties that could cause actual results to differ materially. We disclaim any obligation to update or revise these forward-looking statements unless required by law. Please refer to these disclaimer of risks and uncertainties shown here, as well as those more fully described in our filings with the Securities and Exchange Commission. With that, I'll hand it over to Baha.
Thank you, Alex. Let me go to the next slide. If I can. All right. Hey, everyone. I'm Baha. I'm the General Manager of Observability here at Elastic. I've been at Elastic for 11 years, and it's a pleasure for me today to present you with our new metrics offering. Our new metrics offering has been launched almost at the beginning of our fiscal year in June. What we've done with this new metrics offering is entering this market with a solution that is not only meeting our customer requirements, but also surpassing some of the best metric solution in the market. You will see in this presentation how we did it.
But in the high level lines, we re-architectured the Elasticsearch for metrics, and we are also meeting our customers where they are, and we also made sure that we're building our metric solution for what our customers are doing today, namely looking at AI workloads. So three characteristic for metric solution. First, it's blazing fast. If you enter the metrics market, you have to be fast, and that's one of the guiding principle for a solution. We looked at benchmark against competitive solution, such as Prometheus and Mimir.
I'll get into the numbers more in details later in this presentation. The other thing we've done is we don't want our customers to go from one solution to another when they have their logs, their traces, and their metrics with us. They need to stay in the same platform. The data store should be the same. It's completely transparent for them to store all those signals with us when they do observability, as well as when they query the data in Elastic or they go through the different experiences we have for observability. Everything lives in the same platform.
Lastly, we build it for AI. When the workload shape has changed with AI, having now agents more than traditional application, it brings much more signals, much more data, and much more metrics than before. So, we thought about our metric solution to be as efficient as possible to cope with that new type of workloads. But before I get into more details about what we've done, just a level setting with everyone. If you're not familiar with what the metrics are, metrics is the main signal in observability.
That is literally what wakes up engineers at 3:00 A.M. in the morning when there is an incident, page people when there is something to look at. So when you use an observability solution, you create rules. Those rules are triggering alerts, and 99% of the time, those rules are based on metrics. So couple of example here on the screen. Say you have an application, a web application, and you're looking at the traffic on this application. You will look, for example, at the number of HTTP requests. This application relies on an infrastructure, on an application stack. There's different technology involved and resources that are allocated to this app.
So you will look at the resource utilization, such as the CPU. Or you can also look at things like the latency of the request going into the APIs you're exposing through this application. So lot of those characteristic of your application are emitting metrics. Your application, your infrastructure are emitting metrics. Those metrics are capturing observability solution, and then you create rules that triggers alerts that then page people.
The thing that has changed is when you look at a traditional application, say, a banking application, and you go yourself as a user in your bank account, and you look at your statement, you scroll through the statement, you click on an item. All of those are predefined path and transaction into those applications that are quite traditional. You have a front end, a back end, a data store, database, microservices, cloud deployments. All of that, I put this into the bucket of a traditional application. So not only those transaction are well known, and in addition to this, like I said, this emits traces, logs, and metrics.
So there is a predictable volume you could expect for it. But for agents, it is very different. AI is really causing an explosion in metrics. When I say AI, you can think about the different type of workload or things you need to observe, such as LLM calls, GPU cycles, RAG queries, agent and harnesses. All of that is creating a new set of observability signals that needs to be captured. The challenge is, as you all know, when you interact with an LLM, there are reasoning steps, and those reasoning steps, they depend on what you are asking for.
It goes into tool calls. Those tools are not necessarily known in advance. Now you have agent calling your traditional application probably exposed through MCP, and it is really unpredictable amount of turns you will get with agent. That causes now a new paradox for customers. First, customers have to think about, how am I going to cope with all that data? We know that there are solution out there that are penalizing customers, and they are not able to keep all the data. The problem with this is, then they start to have blind spots.
They have to compromise on the number of data they can keep. Then when there is an incident, they do not get the full fidelity on what happened. It becomes difficult for them to understand what the root cause is. New challenges with AI. When we started to think about how we will go to market with this new metrics offering, we set couple of guiding principles, and I will explain those more in details in later slides.
First, we introduced a new way to store metrics, and not only to store them, but also to manage them. It comes with functionalities that will automatically roll up, down sample or compress the data. Second, we wanted to make sure that users of metric solution will feel familiar when they land with Elastic and use our metrics offering. We put a particular attention to support standard in the market such as PromQL, and we will see that. Lastly, again, we build it for the AI scale.
You saw that AI is bringing more data and new things to observe, and we build it for that with the efficiency that is required to cope with that workload. You know Elastic probably for logs. Our customers are trusting us for their messy logs. We are more than happy to receive all that unstructured data. At the core, we are a search engine, so very good for structured and unstructured data. Logs are flowing in. They get into a document store. We extract those fields, and then we make them available for aggregation.
We can full text search on it. That is our story on logs and how we do it. We use a document store. For metrics, the game is very different because metrics have a different shape than logs. There are numbers. They come with labels. For example, you have something like a number that represent the CPU usage. You have a timestamp. You have dimensions. It belongs to this host that is deployed on this Kubernetes pod, that is deployed on this region of the world, that is deployed on this cloud provider, et c. So many different dimensions.
For this to cope with metrics, we completely re-architectured Elasticsearch for it. We build a column store within Elasticsearch because metrics are coming with their own challenges. I just talked about the dimensions. First, the dimensions is something that is very hard to manage for existing metric solution in the market. We wanted to make sure that we were not limiting our customers in terms of the cardinality. Those are the words you will hear a lot with metric solution out there. Cardinality is something we don't want to limit.
You can have as many dimensions as you want. Then we say that, and then our user is like, "Okay, but what does that do in querying?" Because when you have a lot of dimensions, it start to be difficult to manage all that data in memory. Column store are really well architecture or really it's a great fit for metrics. Because say you have 30 dimensions. Going through 30 dimension when you query has its own challenge. When you go to two dimension out of the 30, you need to just take those two dimension and not parse the data for the 28 left.
That creates some challenges in memory that we actually solved with techniques like dim filter. We also solved how we can manage the data on storage and make sure that it's efficient by tuning our codecs. We use a lot of techniques, as many techniques as we can to make sure that our columnar data store is efficient for querying and for storage. The numbers are telling. We have documented our benchmarks. They are available online.
You have them in GitHub as open source code, so you can run it and verify those numbers. What we've done for logs, we've done it also for metrics, and we're very proud of it. We're benchmarking regularly against the noted competitors here to be 30 times faster than Prometheus and Mimir, eight times faster than ClickHouse, and get storage efficiency for our customers. So when they think about consolidating their metrics alongside their logs they have with us, they see immediately performance gain and immediately storage efficiency. Like I said, we have logs that goes into document store. We have metrics, logs and traces to document store.
We have metrics that goes to column store. We have vectors that goes into vector store. But what does that mean for observability? We have this platform with integrated stores that benefits our users for observability. How we do that, imagine that question on the right-hand side, why is checkout slow? Imagine a user will ask it through our AI agent or directly an AI agent through investigation will ask this type of question in natural language through the reasoning. Those are going through many data layers, metrics.
It goes down to traces, looks at the signals in traces and services, and then drills down into logs. Maybe the customer will bring their knowledge base, and this knowledge base is vectorized. You can see that bringing all those data store in an integrated way and an efficient way allows us to be ready for this type of reasoning that is done with AI through agentic or through directly with our users through chat. We are enabling our users to RCA this way with those different data store integrated together.
We build it for AI scale, but we also build it for a product that we have been cooking for quite some time. You probably have seen that recently, we made the acquisition of a company called Deductive AI that is specialized in RCA investigation with agents. If you are there in New York on October 8th, you will hear from us one of our bigger announcements in Observability. We have worked quite a lot on our AI story solution, so we are very excited to share this with you. Stay tuned and come and attend our ElasticON on October 8th in New York to hear more.
We launched our metrics offering. I have talked a little bit about our storage efficiency and performances, but our metrics offering is also coming with a ton of functionality, which I try to categorize for this webinar into those three categories with functionalities that relates to meeting our customers where they are with PromQL. Giving our customers with rich content so they do not have to rebuild anything when they use our metrics offering, and integrating this with different consumption surface than our UI for our customers' harness and agent, and making sure that our AI agent is also ready to serve with metrics insight within our solution.
I will go through some of it now. The first thing we wanted to make sure we had is PromQL native support with our Elastic metrics offering, which means that a user can take their PromQL queries, copy and paste it into Kibana, and it will just work. To do this, we are using the most popular dashboards out there that are using PromQL and making sure that we are bringing 100% compatibility. We reached 90%, and we are on track to get to 100%. Our users feel familiar with our metrics offering by querying with PromQL, and also can use our AI agent to generate those queries directly into the solution.
The other thing that our customers are asking us, and specifically, the logs customers we have that wants to bring their metrics alongside their logs with us is to help them migrate. Of course, we have a professional services team that does that. We felt that we needed also to have tools in the solution that will help customers to migrate from their solution to us. We are delivering this as part of the solution today.
The experiences with build, we actually think about the existing experience we have and adapt it for metrics. We actually rebuilt them for metrics. When I say rebuilt an experience, that means delivering content out of the box. Content is dashboard, visualization, alerts, SLO, skills, machine learning jobs, workflow. All of that comes into an experience. They are fully loaded. We started with Kubernetes, which has the highest demand. We have AWS. We are working on other integration today.
We even went above and beyond in terms of how we think an experience should be, with, for example, integration with technology partner like Temporal, Supabase, and Vercel, where we have not only experiences as shown on the screen, but we also have managed endpoints. What does that mean? It means that a user that uses, for example, Vercel, can point to our metrics endpoint, send their metrics, and we will manage that ingest for them. It will scale as the data comes through. They will land into our solution and immediately have the experience they need for Vercel.
This is the type of end-to-end experience that we're building for our customers. Not only we have specific technology endpoint to manage that intake of data, but we also have OTel and PromQL parameters endpoints to bring the data into our metrics offering. The other thing we want to do is to democratize metrics for any users. If you're not a PromQL user and you don't have necessarily that expertise, and you want to be able to query the data, you can do that in natural language directly into our agent.
More importantly, our users start to tell us that on day zero, the way they consume observability is not necessarily into our UI. They're directly going into their agent and calling the tools and skills that we expose for them to consume the insight they have into our observability solution. We are fully embracing this, where, like I said, we're delivering MCP server, tools, skills, but also MCP app. What you see on the screen is our observability MCP app. You can interact with it. It will give you insight on the anomalies that exist in your system, the blast radius of an incident.
All of this can be done outside of our UI in Cloud, for example, in Cursor, you name it. The harness that our users are using is where we're going to meet them. Lastly, in terms of go-to market, we have three plays. First, we want to make sure that we are going and seeing our logs customers and attaching metrics to it because this is one of the demand that our customers have. They want to be able to investigate through their observability signals, all into the same place, versus going into different solution. That alone is a huge opportunity for us.
Second, we also have the PromQL shop. Users of Prometheus and PromQL who want to see immediately efficiency in terms of the query, efficiency in terms of the storage, but also scalability and not limited cardinality. This is also a place where we go and help our customers to consolidate in Elastic. The last play is for the customers that are being penalized to either keep metrics for a longer time or bring custom metrics, or just use metric solution.
Some of the solution out there are really penalizing in terms of the pricing. That then creates the consequences that I've said at the beginning, blind spots, which is not ideal when you have incidents. We want to win on the economics and go after that portion of the market as well. All right. With that, I'm finished. I will hand it over to Alex.
Yeah. Thanks, Baha. Now we are going to present a quick Elastic customer video from Norion Bank, discussing their observability strategy and their use of our new metrics offering. After that, we will proceed to Q&A.
My name is Per Lindblad, and I am an Observability Platform Engineer at Norion Bank. My role is to make sure our engineer teams have the visibility they need to understand and operate their services reliably. We support multiple development teams across the organization, helping them troubleshoot faster, improve reliability, and get better insights into how the application behave in the production environments and test and CI and so on.
I am Johan Andersson, Observability Platform Engineer at Norion Bank. I have been part of the Norion family now for almost four years. First as a consultant, now full-time. Our team runs the observability platform that the rest of the bank builds on. Ingest the Elastic infrastructure itself and tooling around it and helping teams out with any problems they may have.
Yeah. One of the biggest challenges today is simply the amount of data. Modern environments generate huge volumes of logs, metrics, and traces. The challenge is not to collect data anymore, it is turning the data into actionable insights.
A few challenges we have, I would say one of the obvious for us being a bank is the compliance versus velocity. DORA and GDPR, which are regulatory systems, mean that every change and pretty much every log line is auditable. That pulls against the delivery speed that the business wants. Then there's the telemetry volume.
Our data grows faster than the value we get out of it, so we're constantly making calls on what to keep and for how long. That is without going blind the moment something breaks or when we're reviewing a past incident. I would say that my main concern is that the question often becomes how do we make this cheaper, instead of how does this get us out of incidents faster?
We at Norion Bank have been using Elastic for eight years, I think, give or take. Our usage has grown significantly over the time. Initially, we focused primarily on centralized logging. As our observability maturity increased, we expanded into metrics, APM, distributed tracing, and OpenTelemetry, and so on. Today, Elastic plays a much broader role in our observability strategy. Instead of looking at the individual signals in isolation, we can correlate logs, metrics, and traces in the same platforms.
Two things that's very positive about Elasticsearch to me is Elastic Common Schema. Instead of correlating logs across system is becoming a query instead of a integration project, which this has been for us. Then there's the range of Elasticsearch. The same building blocks goes to a small, single-node hobby project cluster to what we have that is a multi-cluster production setup.
We really appreciate is having a unified platform as Elastic is. Our engineers don't need to jump between multiple tools and understand what's happening in our production environment or when they're testing new applications. They can move seamlessly between logs, metrics, and traces, and so on during investigation on a potential incident as well.
We have tested some of Elastic's new metrics features. Specifically, I am quite impressed with time series data stream. We built a small collector for our Azure DevOps pull queues and ingested it into a time series data stream. The storage savings we saw just after a month was substantial. Metrics is really the only signal cheap enough to collect from everything continuously. That gives us a very good baseline on what to alert on. Logs and traces explain why something breaks, but metrics tells us that it is starting to break and how bad it is getting.
For us, many of the failure modes we look at is things like heap, disk watermarks, ingest lags, and that sort of thing, and those are mostly gradual and show up in metrics long before any user notices anything is wrong. We pay a lot of money for this, and being able to have the data, it is very important for us to be able to quickly identify when something is breaking because even though observability costs a lot, it does so due to the fact that we will have a very good tool to see that things are breaking before and being able to circumvent them.
Time series data works by declaring the dimensions. It lets Elasticsearch co-locate and sort series together, so compression gets much better without really costing any query performance. In our new non-production environment that is eventually going to be our entirely new setup, we have integrated Kubernetes using Elastic Agent to monitor and collect logs from pods and so forth. The experience is that it works really well. Nothing more to say. It just works.
Thank you. At this time, if you would like to ask a question, please click on the raise hand button, which can be found on the black bar at the bottom of your screen. When it is your turn, you will receive a message on your screen, and then you will hear your name called. Please accept, unmute your audio, and ask your question. We ask that you please limit yourself to one question today. We will wait one moment to allow the queue to form. Our first question today comes from Rob Owens at Piper Sandler. Rob, you may now unmute your line and ask your question. Thank you.
Great. Thank you very much, and thank you for doing this. Maybe you can, at a high level, just talk about how long it took you to re-architect this solution in terms of either dollars, man-hours, and what type of competitive moat this provides you relative to the competition, and for how long. Thank you.
Thanks for that question. I can definitely address that. This has been in R&D for a good, I want to say, 12- 18 months at least. We launched this in June, and it was probably in development for a good 18 months prior to that. In terms of the competitive moat, Baha touched upon this a little bit, but we always get an asymmetric advantage whenever we add innovation to the platform.
As you are all aware, we have had a very strong platform when it comes to dealing with unstructured, messy logs. What we have done over here is we have extended that kind of a benefit to a brand new use case where some of our customers had been using us in some capacity in the past, but this is the first time we have introduced a purpose-built solution right in the platform for the proliferation of metrics, which is happening. That is where we expect our sustainable advantage to be.
Thank you.
Thank you. Our next question today comes from Howard Ma at Guggenheim Securities. Howard, you may now unmute your line and ask your question. Thank you.
Great. Thanks. Can you help us bridge customer adoption of Elastic for metrics today to a future steady state? I believe about 2/3 of the business today is tied to logs, either operational logs or SIEM. How are you aggressively marketing metrics to that entire base? On a related note too, how do you think Elastic will be used alongside other metrics platforms? Will it be incremental to usage of other metrics platforms, or more importantly, how do you ensure Elastic becomes a primary metrics engine versus the competition out there?
Definitely. It's a great question, Howard. The way to think about our proliferation today in customers, you did mention adoption in logs as well as on the SIEM side in security. Where this offering plays is really on the first part, of course. It's more towards SRE teams who have been using us as a centralized logging platform. If we look at that customer base today, most of them use a second and third tool for doing things like infrastructure monitoring, et c. The, let us call it, the economic value of that may even far exceed the value that we are providing when it comes to log analytics.
That is what presents the opportunity for us to go after a part of what you mentioned, the log analytics platform for SREs, and then go to that customer base and attach metrics to it. That's really the, let us call it, the shortest term opportunity. Now, to your second question on do we anticipate other tools as well?
Practically speaking, these kind of adoptions are gradual. In some sense, this is a newer product for us in terms of our purpose-built solution over here, which we launched only at the end of June. Practically speaking, we will see a gradual kind of adoption over there. We do expect some coexistence with other tools in the short term. Our goal, of course, is to provide a consolidated solution for all of our customers' logs, metrics, and traces.
Thank you. Our next question comes from George McGreehan at Bank of America Securities. George, you may now unmute your line and ask your question.
Hi, this is George McGreehan on for Koji. I appreciate you taking our question today. Kind of following up on that last question there, do you think there are any sort of product unlocks that are required to take maybe a customer's existing metrics use cases, all of them, and consolidate all of them onto Elastic? Then maybe, a second part to the question, kind of ultimately, what is kind of the uplift opportunity on the average logs customer that you have if you can consolidate all their metrics? Thank you.
Yeah. So definitely, I mean, the product unlocks are a lot of the things that Baha presented. I think as I had alluded to in one of my prior answers, since we have an open platform, our customers have been using us for all signals in some sense in an incidental fashion. So a lot of our customer base do enjoy us for log analytics, so majority of them use us for log analytics, and some of them, they were using our platform for other use cases as well. The specific unlock that was required over here was an efficient, blazing fast store.
The one thing to remember is we are definitely piggybacking on an inflection point that is happening with AI. And that inflection point comes in two ways. It comes with the larger amounts of infrastructure which are getting deployed that need to be monitored, as well as a whole bunch of agent activity and so on, which needs to be monitored as well. And that is what has created the need for a more economic metrics platform at the data store level. So we are using that inflection point to enter the market in a serious way right now.
And that, I would say, is a big part of the unlock, sort of giving us a license to participate. The other part of the unlock is support for things like Prometheus and, sorry, the PromQL query language, because that's how a lot of the metrics business gets done on the SRE side of the house. As well as the ability for customers to just bring the dashboards that they were using in other tools and just migrate them over to Elastic as well. So that is the other part of the unlock.
So think of it perhaps as equal parts, the data store efficiency that AI demands, and on the capability side, support for query languages, dashboards, visualizations, and last but not the least, the ability to be able to chat with your data as well. So those are the unlocks that we actually just released in June. And that does put us in a good spot to gradually take over those metrics workloads from our existing customers as well as go after new customers. In terms of putting a number on it's early days, so stay tuned. The best way to think about it is we have been on one side of observability when it comes to SRE team spend. We can now participate in the other side seriously as well.
Okay. We're just going to transition to some questions that we got over the chat. On AI pacing, if model labs decide to spend more on R&D to ensure safety, how does that impact spend for observability as a category?
Yeah, definitely. We hinted at this in at least a couple places in the presentation as well as in this discussion. AI does provide an inflection point, and I'm going to speak only on the observability side of the house since we are talking about our metrics offering over here. Two very specific ways. One is, of course, as you all know, infrastructure spend is going through the roof, and a lot of that is really in support of all of the agents and the models which are getting deployed. That comes with its burdens of monitoring, at first, the infrastructure level.
Just to understand uptime, understand how many agents are getting deployed, the proliferation of them, and so on. That needs proper observability and monitoring. Goes without saying. The other part of it is what are those agents themselves doing? This is where some of the agent observability side of the house comes in as well, and there is a tie-in over there to properly monitoring agents, both from an uptime health point of view as well as a safety point of view to understand what those agents are doing. There is definitely a time when it comes to how agents are getting deployed, the infrastructure on which they are getting deployed, as well as what the agents are doing.
Okay, great. Last question I have here is what does the adoption curve look like for a standalone metrics offering like the one we just went through today? That's kind of the high-level question. I would say just from our view of it, we just launched this product a few months ago. It has to now go through a traditional enterprise-selling motion, right?
That's a little bit different between a new customer and existing customer. So our sales teams are just getting their hands into this and talking to customers. But maybe, Santosh, you want to spend a little bit of time talking about how you expect to see this product pushed into the market, existing customers, new customers, and how that may look.
No, it's exactly right. We are a couple months since launch, and the early design partners as well as the early engagement has been extremely positive. At the same time, I think as Alex mentioned, these are longer sales cycles. So we do expect adoption to see more of a ramp style as opposed to a hockey stick immediately.
Okay. Thank you. We got one more question here from Tom. Operator, can you let Tom in here?
Sure. Thomas Blakely from Cantor Fitzgerald, you may now unmute your line and ask your question.
Yeah. Thank you, Alex, and thank you everyone at Elastic for hosting this. Very helpful. I think maybe in a different way of asking some of the prior questions is could you compare a metrics data consumption to logs in general, especially for these high cardinality type of AI workloads that you're describing here? Maybe as a second follow-up to that question, we're talking about agentic here and these types of use cases. Is there any other area, maybe security specifically, that you're kind of targeting with these metrics products? Thank you.
In terms of the metrics volume, the best way to think about that is in terms of the data that is coming in, you can almost expect the metrics volume to be in the comparable order of magnitude as logs. There may be one distinction in that people typically like to keep logs around, so on the retention side.
Think of it as data coming in, getting processed, people actioning them, and data that is kept around for long periods of time for retroactive analysis and such. In terms of volume of data coming in, you should assume that it is in the same order of magnitude, and you can do the math from there, as we see in logs. But in terms of data getting retained, we do see logs getting retained for a longer period of time. To address the second question now, I don't know whether that was a fully satisfactory answer, but that's the way-
It was. It was. Thank you
...thinking about the math. In terms of the security side of the house, our focus over here is really on the SRE workload. I do want to clarify that part. This is-
Right.
...mainly for the observability business on the SRE side of the house. On security, there may be incidental use, but I don't want to project that there is going to be massive use of the metrics data store yet. That is something that we are continuing to monitor.
That's helpful. Maybe Alex, if I could squeeze one more in. I think you mentioned to the prior question about the timing here, so it might be premature, but should we think about this as a spend consolidation trend from taking, like you mentioned, like taking spend that's already happening on a workload from another, or is this about net new workloads? That would make a maybe semi easier motion to consolidate the logs and metrics just on Elastic that way. Thank you.
I can address a little bit of this, Alex, which is there is definitely a spend consolidation aspect to it. In some sense, platforms are consolidating around all of these use cases, which is no secret. We do see that spend consolidation. Where I want to say there is a little bit more of sort of the gravy on top over here is the AI part of it.
A lot of our customers are reevaluating their needs based on the additional volumes of infrastructure that they need to monitor and so on. There is a little bit of a reevaluation of existing tools for the new world of AI. Certainly a spend consolidation aspect to it, but with a new lens of higher amounts of, let us call it infrastructure and metrics to be used for monitoring. Alex-
Perfect sense.
...you wanted to add anything over there?
No, I think that nailed it.
Yeah, it did. Thank you so much, guys.
Thanks, Tom.
Well, that concludes the allotted time for today's Q&A session. I will now hand the call back to Alex Kurtz for closing remarks. Thank you.
Yeah. Thanks for joining our call today. If you have any follow-up questions, please reach out to us at ir@elastic.co. Thank you.
This concludes today's conference call. You may now disconnect.