{"id":696,"date":"2026-06-30T05:00:21","date_gmt":"2026-06-30T05:00:21","guid":{"rendered":"https:\/\/struct.ai\/articles\/stratis-health-rca-framework-software\/"},"modified":"2026-06-30T05:00:21","modified_gmt":"2026-06-30T05:00:21","slug":"stratis-health-rca-framework-software","status":"publish","type":"post","link":"https:\/\/struct.ai\/articles\/stratis-health-rca-framework-software\/","title":{"rendered":"Stratis Health Root Cause Analysis Framework: 9-Step Guide"},"content":{"rendered":"<p><em>Written by: Nimesh Chakravarthi, Co-founder &amp; CTO, Struct<\/em><\/p>\n<h2>Key Takeaways<\/h2>\n<ul>\n<li>\n<p>Root cause analysis (RCA) is a structured, systems-focused process that finds underlying conditions causing software incidents instead of treating symptoms.<\/p>\n<\/li>\n<li>\n<p>The Stratis Health 9-step framework gives engineering teams a proven, repeatable method for thorough incident investigations with clear checklists at each stage.<\/p>\n<\/li>\n<li>\n<p>Common RCA pitfalls include blame culture, tribal knowledge silos, runbook drift, and weak corrective actions that fail to prevent the same incident from returning.<\/p>\n<\/li>\n<li>\n<p>AI-powered automation can cut manual RCA time from 30\u201345 minutes to under 5 minutes by handling data correlation, timeline generation, and first-pass root cause identification.<\/p>\n<\/li>\n<li>\n<p><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https:\/\/cal.com\/deepanm\/struct-demo\">Struct automates your on-call runbook <\/a>so this workflow runs the moment your next PagerDuty alert fires.<\/p>\n<\/li>\n<\/ul>\n<h2>The Stratis Health 9-Step Root Cause Analysis Framework for Software Teams<\/h2>\n<p><strong>Step 1: Identify the problem.<\/strong> State the incident in concrete, observable terms without assigning blame. In software: \u201c5xx error rate on the payments API exceeded 15% for 22 minutes beginning at 02:14 UTC, affecting checkout for approximately 4,200 users.\u201d Checklist item: Write a one-sentence problem statement that includes the affected service, the measurable deviation, the start time, and the estimated user impact.<\/p>\n<p><strong>Step 2: Assemble the team.<\/strong> Bring together people with direct knowledge of the affected system. In software: page the on-call engineer, the service owner, and a representative from the platform team within the first 15 minutes. Checklist item: Confirm that at least one person with code-level context and one person with infrastructure context are in the incident channel before proceeding.<\/p>\n<p><strong>Step 3: Describe what happened.<\/strong> Reconstruct the sequence of events in chronological order using objective data. In software: pull the Datadog timeline, Sentry error spikes, and deployment history into a unified view. Automated timeline capture eliminates 60\u201390 minutes of manual reconstruction per incident that teams otherwise spend correlating timestamps across tools. Checklist item: Produce a timestamped event log that covers the 30 minutes before the first alert through full resolution.<\/p>\n<p><strong>Step 4: Understand the process.<\/strong> Map the normal, expected flow of the system and highlight where it deviated. In software: diagram the request path from the load balancer through the API gateway, application layer, and database. Checklist item: Annotate the architecture diagram with the specific node or transition where the failure first appeared.<\/p>\n<p><strong>Step 5: Identify root causes.<\/strong> Use structured techniques such as the 5 Whys or a fishbone diagram to move from proximate symptoms to systemic causes. SRE teams apply the 5 Whys to trace a database CPU spike back to missing query performance checks in the CI\/CD pipeline and code review process. Checklist item: Document at least three causal layers (symptom \u2192 contributing factor \u2192 root cause) before closing the analysis.<\/p>\n<p><strong>Step 6: Design an improvement strategy.<\/strong> Translate each root cause into a specific, testable corrective action. In software: if the root cause is an unindexed database query introduced in a recent deploy, the corrective action is adding a query-plan check to the CI pipeline, which creates a concrete guardrail against similar regressions. To ensure accountability, every corrective action must have an owner, a due date, and a measurable success criterion.<\/p>\n<p><strong>Step 7: Implement the improvement.<\/strong> Execute the corrective actions in priority order. In software: merge the CI check, backfill the missing index, and update the runbook to flag similar query patterns. Checklist item: Link the pull request or infrastructure change directly to the RCA document so the fix remains traceable.<\/p>\n<p><strong>Step 8: Measure and evaluate results.<\/strong> Confirm that the corrective actions resolved the root cause and did not introduce new failure modes. Teams should track repeat incident rates, action item completion rates, and timely resolution of high-priority items. Checklist item: Schedule a follow-up review to verify the metric that triggered the original alert has not recurred.<\/p>\n<p><strong>Step 9: Communicate findings.<\/strong> Share the RCA summary with all stakeholders in a blameless, factual format. Google&#8217;s SRE Book established the cultural standard for blameless post-mortems, which typically include a summary, timeline, root cause analysis, impact assessment, and corrective action items. Checklist item: Distribute the completed post-mortem document within 48 hours of resolution.<\/p>\n<h2>Fishbone Diagrams and Causal Statements for Software Incidents<\/h2>\n<p>Step 5 references fishbone diagrams, and many engineering teams benefit from a concrete example tailored to software. A fishbone (Ishikawa) diagram organizes contributing factors into categories that feed a central problem statement. For software incidents, the standard categories are: <strong>Code<\/strong>, <strong>Configuration<\/strong>, <strong>Infrastructure<\/strong>, <strong>Process<\/strong>, <strong>People<\/strong>, and <strong>External Dependencies<\/strong>. Each branch holds one contributing factor, and the spine points to the problem statement written in Step 1.<\/p>\n<p>A well-formed causal statement follows this template: <em>\u201c[Contributing factor] caused [observable effect] because [systemic condition], which resulted in [incident outcome].\u201d<\/em> Example: \u201cAn unindexed foreign key introduced in deploy #4821 caused query latency to exceed 10 seconds because the CI pipeline lacked a query-plan validation step, which resulted in a 22-minute payments API outage.\u201d This structure, drawn directly from <a target=\"_blank\" rel=\"noindex nofollow\" href=\"https:\/\/cms.gov\/medicare\/provider-enrollment-and-certification\/qapi\/qapiresources\">CMS QAPI guidance on causal analysis<\/a>, forces specificity and prevents vague corrective actions.<\/p>\n<h2>Common RCA Pitfalls in Engineering Teams<\/h2>\n<p><strong>Blame culture masquerading as accountability.<\/strong> Naming an individual as the root cause stops the analysis at the human layer and hides the process gaps that made the error possible. Effective post-mortems focus on contributing factors such as process gaps, tool limitations, and documentation failures rather than individual fault.<\/p>\n<p><strong>Tribal knowledge silos.<\/strong> When the only person who understands a subsystem is unavailable at 3 AM, the RCA stalls. This happens because runbooks live in a senior engineer&#8217;s memory rather than in a shared, versioned document, creating onboarding bottlenecks and extending MTTR on every recurrence.<\/p>\n<p><strong>Runbook drift.<\/strong> A runbook written six months ago for a monolith does not describe a microservices architecture. Corrective actions that are never implemented, or implemented but never documented, cause the runbook to diverge from reality until it becomes actively misleading.<\/p>\n<p><strong>Weak corrective actions.<\/strong> \u201cBe more careful\u201d and \u201cadd monitoring\u201d are not corrective actions. Each action must specify what will change, who owns it, and how success is measured. Without that structure, the same incident recurs.<\/p>\n<h2>From Manual RCA to Automated First-Pass Investigation<\/h2>\n<p>Each of these pitfalls, including blame culture, tribal knowledge silos, runbook drift, and weak corrective actions, often stems from manual RCA processes that depend on individual engineers&#8217; availability, memory, and discipline. The nine steps above are rigorous and proven, but they are also time-consuming when executed manually. A standard manual investigation, which includes correlating logs in AWS CloudWatch, tracing exceptions in Sentry, and cross-referencing a recent GitHub deploy, takes 30 to 45 minutes before a human can even begin writing a causal statement.<\/p>\n<p>AI-powered platforms now execute the same systems-thinking workflow in real time. Struct integrates directly into Slack and PagerDuty, and the moment an alert fires it automatically queries logs, correlates trace IDs, maps the event timeline, and surfaces a root cause with suggested fixes in under five minutes. By the time an engineer opens their laptop, Steps 3 through 5 of the Stratis Health framework are already complete. The engineer reviews a dynamically generated dashboard instead of hunting across five separate SaaS tools.<\/p>\n<p>Struct also ingests custom on-call runbooks, so the automated investigation follows the exact operational procedures a senior engineer would apply manually. This directly addresses tribal knowledge silos because the runbook is encoded once and applied consistently on every alert, regardless of who is on call.<\/p>\n<p><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https:\/\/cal.com\/deepanm\/struct-demo\">Encode your runbook once, apply it on every alert<\/a> and see a live Struct investigation on your own stack in ten minutes.<\/p>\n<h2>Evaluation Criteria for Your RCA Process<\/h2>\n<p>The following table compares manual and Struct-automated RCA across four dimensions that shape how well your team learns from incidents and prevents repeat failures.<\/p>\n<table style=\"min-width: 75px\">\n<colgroup>\n<col style=\"min-width: 25px\">\n<col style=\"min-width: 25px\">\n<col style=\"min-width: 25px\"><\/colgroup>\n<tbody>\n<tr>\n<th colspan=\"1\" rowspan=\"1\">\n<p>Criterion<\/p>\n<\/th>\n<th colspan=\"1\" rowspan=\"1\">\n<p>Manual RCA<\/p>\n<\/th>\n<th colspan=\"1\" rowspan=\"1\">\n<p>Struct-Automated RCA<\/p>\n<\/th>\n<\/tr>\n<tr>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Investigation speed<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>30\u201345 min to root cause<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Under 5 min to root cause<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Consistency<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Varies by engineer experience<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Uniform across every alert<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Onboarding readiness<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Requires tribal knowledge<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Runbook encoded; junior engineers unblocked<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Post-mortem completion<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Manual reconstruction required<\/p>\n<\/td>\n<td colspan=\"1\" rowspan=\"1\">\n<p>Timeline auto-generated at alert time<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>All Struct performance figures above reflect the company&#8217;s documented 80% reduction in triage time and the Series A fintech case study in which average investigation time dropped from 30\u201345 minutes to under 5 minutes after a 10-minute setup.<\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>What is the root cause analysis model in healthcare?<\/h3>\n<p>The Stratis Health RCA model is a nine-step, systems-focused process used to investigate adverse events in healthcare settings. It begins with a clear problem statement and proceeds through team assembly, event description, process mapping, root cause identification, improvement design, implementation, measurement, and communication. The framework is explicitly non-punitive and treats failures as the product of system conditions rather than individual error, which is the same cultural foundation that Google&#8217;s SRE Book established for software post-mortems.<\/p>\n<h3>What are the 5 steps of root cause analysis?<\/h3>\n<p>Condensed versions of RCA typically include: (1) define the problem, (2) collect data and reconstruct the timeline, (3) identify contributing factors using a technique such as the 5 Whys or fishbone diagram, (4) design and implement corrective actions, and (5) measure results and communicate findings. The Stratis Health nine-step model expands this structure to include explicit team assembly, process mapping, and improvement strategy design as discrete steps, which increases rigor and accountability in complex, multi-team environments.<\/p>\n<h3>How is RCA different from a standard incident post-mortem?<\/h3>\n<p>A post-mortem is the document, and RCA is the analytical process that produces the most important section of that document. A post-mortem without a structured RCA often stops at the proximate cause, such as a bad deploy or a misconfigured flag, and generates weak corrective actions. A structured RCA pushes the team to identify the systemic condition that made the proximate cause possible, which is the only level at which a corrective action can prevent recurrence.<\/p>\n<h3>Can Struct replace the human RCA process entirely?<\/h3>\n<p>Struct automates the data-gathering, correlation, and first-pass root cause identification phases of the RCA process, which correspond to Steps 3 through 5 in the Stratis Health framework. The corrective action design, implementation, measurement, and communication steps still require human judgment and ownership. Struct&#8217;s role is to eliminate the manual log-hunting work described earlier so engineers arrive at the human decision points faster and with complete context.<\/p>\n<h3>Is Struct compliant with security and data requirements?<\/h3>\n<p>Struct is SOC 2 and HIPAA compliant. Logs are accessed and processed ephemerally. For organizations with strict requirements that prohibit any data leaving their VPC, Struct is not currently the right fit. Setup across all plans takes under 10 minutes and requires only authentication of an issue source, a code repository, and an observability platform.<\/p>\n<h2>Automate Your On-Call Runbook<\/h2>\n<p>The Stratis Health nine-step framework delivers the rigor that turns a reactive fire-drill into a repeatable, learning-oriented process. Struct encodes that exact workflow and executes it automatically on every alert, cutting triage time by 80% and giving engineers a complete root cause before they open their laptop. As noted earlier, setup is complete in under ten minutes, and the first automated investigation runs immediately.<\/p>\n<p><a target=\"_blank\" rel=\"noopener noreferrer nofollow\" href=\"https:\/\/cal.com\/deepanm\/struct-demo\">Start automating your on-call workflow<\/a> and run a live pilot on your own stack today.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Master the Stratis Health RCA framework for software incidents. Struct automates root cause analysis from alert to corrective action \u2014 in minutes.<\/p>\n","protected":false},"author":73,"featured_media":695,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-696","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/posts\/696","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/comments?post=696"}],"version-history":[{"count":0,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/posts\/696\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/media\/695"}],"wp:attachment":[{"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/media?parent=696"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/categories?post=696"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/struct.ai\/articles\/wp-json\/wp\/v2\/tags?post=696"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}