 When it comes to software delivery and operational performance, the Devil's Research and Assessment, or DORA, has developed metrics to measure the effectiveness of organizations' development and delivery practices. Not only can these metrics be used as a common way or an industry standard to compare how well organizations are doing, but they can also help leaders and teams measure and improve what matters in relation to their software delivery and performance. There are a total of five metrics, which are the following four, plus availability. We'll cover the time to restore service metric, defined as the length of time that it generally takes to restore service when a service incident or a defect that impacts users occurs, for example on planned outage or service impairment. The specific feature introduced in GitLab 14.9 that we will cover is Project Level Time to Restore Service API. This is our first MVC of this feature and as customary, with our DORA metric implementations, we are first releasing the Project Level API for it. A feature iteration will include the Group Level API. Let's see how this new feature works. For a GitLab project, the specific calculation for the time to restore is the median number of seconds an incident was open during a time period. This metric is only available for production environments. We see the GitLab project named PlanExec, which has a production environment. This project does not currently have any incidents against its production environment. If we run the API for the time to restore for this project with a time interval of daily, which is also the default, we see that the value is null, indicating that we have not had any unplanned outages yet. Let's head over to Monitor Incidents and create an incident against this project. For this MVC, the assumption is that all incidents are for production environments. A feature iteration will allow you to associate an incident to a specific environment. We will simulate the time that it took to resolve this incident by waiting a few minutes before we close it. Now that a few minutes have passed, let's go ahead and close the incident. At this point, let's rerun the API. The time to restore Dora 4 metric is now returned by the call to this API. As you can see, there is now a time to restore metric of 406 seconds with today's date. As more incidents take place and are handled, this return value will be adjusted for the specified time interval, which can be daily, monthly or all. For example, a day later and after the creation of a few more incidents, which we close to have GitLab calculate the time to restore metric, we rerun the API with the daily time interval and we see that the median for today's time to restore times is 3761 seconds. And if we run the API with the all time interval, we get the median value of 2083.5 seconds. The calculation and display of the time to restore Dora 4 metric provide insight into the effectiveness of your development and delivery practices without having to spend time calculating this metric by hand. It also helps you better measure and improve what matters in relation to your software delivery and performance.