### Problem to solve Reviewing the runbook is one of the first things to happen during an incident investigation. Often the runbook can help the responder restore an outage in minutes. Rendering this directly in the incident streamlines remediation workflows. ### Intended users * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) ### User experience goal Ensure that all context relevant to resolving an incident is accessible from the incident itself. ### Proposal When available, surface the runbook details within a separate tab on the incident issue type:  ### Further details This works supports the [Incident Management](https://about.gitlab.com/direction/monitor/debugging_and_health/incident_management/) direction. ### Permissions and Security ### Documentation ### Availability & Testing ### What does success look like, and how can we measure that? ### What is the type of buyer? ### Is this a cross-stage feature? ### Links / references [Figma file](https://www.figma.com/file/EqXIfhBIh9McdO4UHZRf4t/Dedicated-incidents-gitlab-com-and-218694?node-id=63%3A342) <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->