 Okay, welcome to our last tutorial of the day. Monitor health stage. I mean, this is a relatively new group. We actually have a pretty active number of contributors that have been contributing to this group, but I wanted to have give Sarah an opportunity to talk to the community members and potential contributors. So happy to turn things over to you, Sarah, and let's introduce yourself and go from there. Thanks, Ray. Hi, everyone. My name is Sarah Wildner. I'm the senior product manager for the health group, which lies within the monitor stage. And so today, I'm going to give a bit of an intro into the health group, where we lie within the GitLab organization, our direction, mission, what we're responsible for. Do a high level dive into the categories and areas that we're currently prioritizing working on, and then tell you how everybody can contribute to our mission. So as I said before, the health group is part of the monitor stage. The monitor stage is actually made up of two groups. We've got the health group, which I lead, and then our other group is the application performance monitoring team. So in a nutshell, the health group at GitLab is responsible for building tools utilized by DevOps teams to triage and remediate errors in IT incidents for systems and applications that they maintain. So essentially, we are building tooling to help streamline and make very simple and efficient all of the processes and workflows that go into reviewing, triaging lists of alerts or errors from systems, which are often very cluttered and noisy, adding functionality that makes it easy to dig through your craft and come up with what is most important, and then route that to the right person and team, and provide tools to help them collaborate and fix those as quickly as possible to manage and return services that they provide to their customers to meet their service level objectives. So, right now, this is a newer group within one of the newest stages at GitLab. Monitor is less mature than our create for our planned stage, which has had products in Maca for about seven years. We've had a lot of our products in Maca for about two years. So today, our mission is to decrease the frequency and severity of IT incidents via tools that allow you to respond really quickly and also make your systems more observable. A little bit more on where we lie within the GitLab organization. So here's the DevOps loop. Everyone's very familiar with this diagram. We sit in an interesting place. We sit at the end of the DevOps cycle where you feedback into the planned stage. So I think this is really interesting because this is a connection that is not often talked about from an operations perspective. Alert and incident management are actually key to completing this DevOps loop. It is how you identify and learn about system and application problems that you need to fix. And then those improvements to make sure those problems never happen again. We help you feed those back into the planned stage. So the categories that we are responsible for. We've got five overall. Some we are actively developing for because we've prioritized them in GitLab Universe. And then another one we are aware of and we are gathering market and user feedback so that it's awaiting further demands. We can prioritize it later in our roadmap. So the places we are actively developing and focusing a lot of our energy are alert and incident management, which are all part of that triage workflow. Using and learning from your monitoring tools making your systems more observable so that you can efficiently respond to problems and fix them as quickly as possible. In relation to that, we are also responsible for GitLab status page, which we just shipped to the minimal maturity in the last couple of months. This is really exciting. The status page is where you can publish details of a GitLab issue to a public URL so that business stakeholders and customers stakeholders can follow along as you manage and track that problem and restore services. And your response teams can remain within GitLab. And then our error tracking product, which we just spent a significant amount of time in the last six months is based on an integration with the open source tool of Century. And we are right now. Dogfooding that internally. We are measuring usage of that. And while we do not have a roadmap plan for that category in the future, we're always excited to accept and write requests to that particular category. And last but not least, digital experience management is one of our categories that is awaiting further demand. Digital experience management is a very broad category. So that's going to encapsulate everything from real user monitoring, synthetic user monitoring, API monitoring, uptime browser monitoring. Everything that has to do with tracking and making sure that the user experience for your application is performing. It goes much further than your typical errors per second latency or request per second. A handful of metrics that you might track from an application performance perspective, and takes it to the perspective of the user to make sure that in real time you understand how people are experiencing and interacting with your application. So we're not currently prioritized this, but we're always looking for feedback and engagement. So a quick question. Some of these features, I mean, are, I mean, I don't know if there's an easy way to quantify this are, I mean, do you, is there a breakdown of like the amount of feature that's in the enterprise edition only versus in the pre communities edition product. Yeah, that's a great question. So status page as a whole lies within our ultimate product. That's for the enterprise. Alert management incident management and error tracking. All have implementations that are available in the core. Those are all critical to closing the DevOps loop and we want to provide an experience for teams of all sizes to be able to detect understand and remediate it problems. And as we progress those and as those categories mature, we will be adding more to the premium and ultimate levels, but some part of all of those categories, excluding status page exists in core. Cool. So it sounds like a significant portion of it is available in the community edition. Yes. Yeah, I was looking at community contributions over the past year or so. So one that was for the enterprise edition but it looked like recipe more just available for for everyone. So, yeah, thank you so much for asking that question I think it was really important for everybody to understand that. And then last but not least, everyone can contribute. I've been shared in a bunch of the other tutorials, but searching for issues within your lab, something merge requests, and then the label for group health. And then you can also add on the category labels for a particular area of your specific interest in that. And then mentioning me directly on any of those issues and I can answer any of your product and design questions. So we're happy to like have these like assigned to you if you're really interested in working on them either Sarah or myself at our peak and happy to help you get partnered with the right folks and in the health team. All right, Ray, that's all I have for this tutorial. Can I add anything else. I was actually going to ask Regendre and put him on the spot if that's okay Regendre, but I know you've, I mean, started making a lot of contributions to the month to the health group over the past several months like I mean if you want to share your experience on how you got started why you were interested in the in the group and who you've been working with I think that would be helpful for contributors that might be interested. Oh yeah okay so I found out like this is error tracking was at very early stage when I started, I think it's still at an early stage we have just integration with sentry and not any other providers like as Sarah mentioned we are not investing much time on it. So yeah I think I started with adding APIs for basic grid functions of error tracking settings getting them, deleting them, changing them. And it was very interesting to work on it from scratch because there was not much code but there was a lot of help from Peter from the monitor states team. And yeah, to be honest, it was really exciting for me to work on and that's the main reason I started working even in the ops call. I think sister's called out about why are there many contributions in the monitor stage are the numbers for something something like that so yeah I think that's yeah. It was interesting for me to contribute. Cool yeah I mean, I need want to apologize you for I mean you were very proactive in terms of like trying to get in touch with people, not just me and Sarah but I know you've been working with you mentioned Peter and Clement and others. So, I mean I think it's a living proof that we have a really, I mean, friendly group of people in the in the health group team. So people are interested in working on any of the features I have questions. And it should be relatively relatively easy to get started. So definitely want to encourage more people to help out and participate. Yeah, I never faced an issue about like not having started in some amount of some issue. I mean, like within a couple of hours I had some really useful response for the issue. Cool. Sorry, I think you're breaking up a bit there, Regender. Can you repeat the last sentence. There was a saying someone is joined to. Oh, okay. Yeah, it looks like Sasha just joined Sasha were actually like towards sort of the end of the presentation but I had a problem adding the link to the presentation on the hackathon page for what a reason I'll update that but here's a link. Oh yeah, I just got it. Okay. Cool. Sarah, anything else that you want to add or that's it. Thanks. Right. Oh, thank you very much for doing this. And. All right, so we'll wrap things up and we'll see each other again soon. Chris.