 All right, it's time to get started with the functional update in that work. There we go. Welcome to the Peretius team functional update. I'm Ben Kochan, the lead for the team. We have Joshua, Jose, Mike, and Paolo on our team. And we also have two contractors, Kevin and Ulis. We spent some time on 10.0 to try and get us to influx to be feature parity and worked on that a bit. But it's still not complete yet because we've been having quite a lot of problems with our Ruby Gym that is causing it to be not stable. So we could definitely use some help. Part of the thing going on with getting this work done has been the fact that Paolo has been out sick for the last few weeks. So we've been making only a small amount of progress since we have been trying to keep him from working and recovering instead of stressing himself out more and continuing to stay sick. So we did ship in 10.0 application performance metrics. So this allows application metrics instead of just system metrics for things like this example of HTTP request throughput. Coming up in 10.1, we're going to, because Paolo has been out, we're going to focus on stability and bug fixes, stabilizing the Ruby library and dealing with some front end display issues. Peretius in production, we've removed the system to unit state metrics from the production service for goodlab.com. This now reduced the amount of overhead on Peretius by about 25%, which was quite a lot of data for not a lot of utility. And that's it. That's a very short update today. What does influx to be feature parity mean? Basically, we currently have a bunch of metrics that we get out of the goodlab CE Rails libraries. Those metrics are going to be deprecated as soon as we have all of these same metrics available in the Peretius library. For right now, we don't have that because the Ruby library is not quite stable. So we have not been able to officially deprecate the influx to be metrics. Yeah, Mike, as Bennett, it's just basically influx is the older way that we had metrics in goodlab as being like it exporting information about itself. And so we've been converting over to Peretius. We obviously feel it's a better solution for a variety of reasons. And we've been going through and making sure we have parity for all the monitoring capabilities that were in the previous method influx that are also in Peretius. That way we can deprecate the old one and plow ahead on the new Peretius features. It is worth noting that it's not like we have a subset right now. We also have things in Peretius that were never available on influx as well. So we're just making sure we cover our bases and make sure that we add everything that was previously possible along with all the new stuff we've done. This will also help us run and operate kitlab.com, obviously, as well. So this is important for that as well. Any other questions? Yeah, just add a little more color on the customer side of the application side as well. So we did a lot of work on the front end charts as we have seen in that one little screenshot there. So some of the look and feel has changed a little bit and we added support for multiple series in a single chart. So before you can only have one sort of metric rendered on a single chart. And so we couldn't do things like show you, say, like the throughput by request type. And so you couldn't see, for example, how many successful requests you had and how many perhaps errors you had on your request. And so this now allows us to chart multiple things on the same chart area. So that's really helpful for some fields like that. But it also helps us lay the foundation for our canary support as we have to be able to render, obviously, the canary versus production. And we need support for rendering multiple lines and then having a legend update and things like that as well. So Jose has been working hard on that along with Mike. Yo was asked to get an idea of these adoption of these features in GitLab. Yes. So we do collect those. And so Prometheus, the number of Prometheus projects or the number of projects with Prometheus enabled is something we track with our sort of version paying usage paying feature. And so we have an easy way to check on those and see how we're doing. And basically, we're right around 5,000 projects with Prometheus enabled. So that's that's pretty good. Considering back in May, we started with a total of, I believe, 131. And now we're up over right up actually over 5,000, 5,028 right now. And that was actually a couple weeks old. So we actually refresh it and see what the current one is. Yeah, that's pretty exciting. We also wanted to get much higher. And so we could do a better job of advertising it and highlighting it within the UI to make sure folks are aware of it. So stay tuned for that, especially as we sort of round up this initial set of features here for Prometheus monitoring. Yep. Any other questions? Okay. Yeah, I think I'm at and I spend noted here for 10.1 taking a little bit of pause on the new feature direction just given some of the resourcing challenges that we have to work with. We obviously wish Pavel all the best and to get better and focus on that. On the interim, we're going to brush some tech debt and take advantage of this sort of breather and pushing forward to polish and resolve some of the kind of lingering minor issues that we had previously. So we'll get positioned to push for the red here well and intend to. Yep. Yeah, Kim says this is where your application metrics would be if you enabled it. And I believe that's actually what the display says. All right, so actually I re I re-upted to the query. We're at 6191 projects last week. So up into the right. All right. Any other questions? All right. Thank you everybody. All right. Thanks.