# The 5-Step Operational Control Flow Every Incident Runbook Should Follow
* **Author:** Sandeep
* **Published:** 2026-08-08
* **Description:** A complete guide to the modern incident control flow: from detecting anomalies and paging responders to deterministically coordinating your application's behavior.
* **Tags:** Incident Management, System Design, Operational State
* **Canonical URL:** https://theruntimehq.com/insights/4-ideal-incident-runbook-operational-control-flow
---
## In this article
You'll learn:
- The complete, 5-step operational control flow during an incident.
- Why traditional runbooks stop at human collaboration and leave the application vulnerable.
- How to integrate application state management into your standard incident response workflow.
- When the incident commander should transition from impact assessment to declaring Operational State.
- Where an Operational State Control Plane fits into the incident management ecosystem.
**The Bottom Line:** Modern incident management excels at detecting failures and coordinating engineers, but it rarely defines how customer-facing applications should behave while those engineers investigate the problem. The missing discipline is Operational State Management.
## The Anatomy of a Modern Incident
### What is an Incident Runbook?
An incident runbook is a predefined set of procedures and workflows that an engineering organization follows when a system degrades or fails. While legacy runbooks focused purely on manual server restarts, modern runbooks dictate how monitoring tools, incident commanders, engineering responders, and applications interact to resolve an outage.
Outages are inevitable. However, a planned strategy in the form of a runbook brings discipline to organizing your engineering response.
If you look closely at standard incident runbooks, they are highly tuned to manage the human workflow. Anomalies trigger Datadog, PagerDuty wakes up the on-call engineer, and collaboration spins up in Slack and Jeli. But during a Sev-1 outage, while your incident commander spends critical minutes assembling context, and engineering teams join a breakout room to diagnose and stop the fire, what is your [application](https://docs.theruntimehq.com/architecture/core-entities) actually doing for the customer?
Most organizations implement this responsibility differently, often relying on application-specific logic or feature flag platforms. It's time to define the ideal runbook-one that treats the application's [Operational State](https://docs.theruntimehq.com/glossary#operational-state) with the same rigor as human alerting.
Protecting the consumer experience during an outage serves a practical purpose beyond preserving brand trust. When users encounter broken UI elements or unhandled errors, it often leads to confused retries. This secondary fallout can distract the engineering team and complicate the incident response. By configuring the application to proactively degrade its capabilities and communicate the issue clearly, organizations can maintain a controlled user experience and allow responders to focus entirely on investigating the root cause.
## The 5-Step Operational Control Flow
### What is an Operational Control Flow?
An operational control flow is the structured lifecycle of an incident, tracing the exact path from the moment an anomaly is detected in infrastructure to the moment the customer-facing application mitigates the impact. It governs both human collaboration and machine reaction.
An incident isn't just about bringing a server back online; it is about managing the user's reality while the server is down. A modern operational control flow standardizes this process across five distinct phases.
### 1. Monitoring & Observability ("Is something broken?")
The flow begins with your telemetry. Metrics, logs, and tracing platforms (e.g., Datadog, Splunk, Elastic, Dynatrace, New Relic) continuously measure the baseline health of your infrastructure. When an anomaly breaches a predefined threshold, these systems detect the fault.
This phase is purely about *signal generation*. It answers the question, "Is something broken?", but it lacks context on business or customer impact. The signal could represent a temporary network blip that auto-restores within seconds, a one-off data anomaly, or a non-critical component failing (e.g., friendly product names failing to load while transactions still succeed). Conversely, it could indicate a critical, cascading failure-such as a container crashing with an OOM error, spiking database latency, or a downstream dependency timing out. The telemetry knows the state of the infrastructure, but it doesn't know the state of the user experience.
Monitoring platforms observe infrastructure health. They do not decide how applications should respond.
### 2. Internal Alerts & Paging ("Who needs to look into it?")
Once a signal is generated, routing systems (e.g., PagerDuty, Opsgenie, VictorOps) take over to alert the human responders. They map the failing service to an on-call schedule and escalate the notification until acknowledged.
This phase is purely about *human mobilization*. It answers the question, "Who needs to look into it?"
### 3. Impact Assessment ("How are we collaborating to fix this?")
This is the most critical and time-consuming phase of the human workflow. The on-call team evaluates the blast radius, affected services, and user impact. Collaboration happens in war rooms, Slack channels, and incident management platforms like Jeli, ServiceNow, or Jira.
The investigation phase is typically the longest phase of the incident lifecycle because responders must assemble context across multiple systems. This gap is exactly why manual "kill switch" feature flags are too slow and risky.
### 4. Operational State Declaration ("How should our software behave?")
While engineers diagnose the root cause, an incident must be declared. Today, this declaration absolutely happens-but it remains entirely internal. The incident is declared in Slack or Jira to coordinate engineering, update the business, and inform the DTL (Digital Leadership Team). Some organizations might take the extra step to reflect this on a disconnected public status page, but the actual *user experience* within the application remains a glaring gap.
Bridging this gap requires declaring the incident not just to humans, but to the applications themselves. This is where an [Operational State Control Plane](https://theruntimehq.com/insights/3-what-is-an-operational-state-control-plane) becomes necessary.
An Operational State Control Plane becomes the authoritative system responsible for distributing Operational State to customer-facing applications.
Instead of hunting down individual application teams to manually deploy banners or relying on disconnected status pages, the incident commander defines the precise **Impact Scope** (which capabilities are affected) and the updated **Operational State** (e.g., degraded, outage). The human makes the deterministic declaration; the control plane handles the global distribution.
### Who is responsible for declaring the Operational State?
Typically, the Incident Commander or the primary responding SRE makes the deterministic declaration in Step 4, based on the reality assessed during Step 3's root cause investigation.
### 5. Instant Application Response (Protecting the Customer)
Impacted applications using edge-optimized SDKs instantly consume the computed Operational State payload and react dynamically. The application natively degrades capabilities, surfaces synchronized customer messaging, and prevents users from encountering raw errors.
This phase is about *machine reaction*. It ensures that the customer experience is protected instantly, buying the engineering team the time they need to complete their investigation without customer-facing chaos.
### Does the control plane sit in the critical request path?
No. A properly designed control plane uses asynchronous edge polling (stale-while-revalidate) so your application never waits for the control plane to render a page. Because the control plane distributes state to edge-optimized SDKs (which locally cache the payload), the application continues to operate on the last known state even if the control plane were to go offline.
```json
{
"state": "RUNTIME_STATE_OUTAGE",
"message": "Payment processing is currently unavailable.",
"capabilityStates": [
{
"capabilityName": "checkout",
"state": "RUNTIME_STATE_OUTAGE"
}
],
"updatedAt": "2026-08-05T10:00:00Z",
"version": "7"
}
```
*Example: The structured JSON payload distributed by the control plane, allowing applications to natively disable the checkout capability.*
### Summary: The 5-Step Operational Control Flow
To summarize, a mature operational control flow aligns human responders and machine behavior into a cohesive pipeline:
| Step | Phase | Key Question Answered | Example Tooling | Primary Focus |
| :--- | :--- | :--- | :--- | :--- |
| **1** | **Monitoring & Observability** | "Is something broken?" | Datadog, Splunk | Signal Generation |
| **2** | **Internal Alerts & Paging** | "Who needs to look into it?" | PagerDuty, Opsgenie | Human Mobilization |
| **3** | **Impact Assessment** | "How are we collaborating?" | Slack, Jeli, Jira | Root Cause Investigation |
| **4** | **Operational State Declaration** | "How should the app behave?" | RuntimeHQ (Control Plane) | Deterministic Mitigation |
| **5** | **Application Response** | "Is the user protected?" | RuntimeHQ SDKs | Edge-Level Degradation |
## The Architectural Gap in Traditional Runbooks
Most engineering organizations have heavily invested in the first three steps, but they attempt to solve Step 4 and 5 by misusing software delivery tools.
### Why can't I just use my feature flag platform as an operational control plane?
Feature flags are designed for audience targeting (Release State), not [capability](https://docs.theruntimehq.com/glossary#capability) targeting (Operational State). Misusing them for outages results in schema drift, inconsistent customer messaging across web and mobile, and a disjointed audit trail during postmortems.
Feature flag platforms answer **who should receive a feature**, whereas Operational State Control Planes answer **how applications should behave during operational events**.
When you hack feature flags to serve as outage banners, you lack a standardized schema. Every frontend team interprets the flag differently, leading to fragmented customer messaging and significant coordination overhead for the Incident Commander. We explore the architectural differences between these two models in our breakdown of [why outage banners don't belong in feature flags](https://theruntimehq.com/insights/1-why-outage-banners-dont-belong-in-feature-flags). For a deeper understanding of how to implement the correct operational architecture, explore [how RuntimeHQ's architecture works](https://docs.theruntimehq.com/architecture/how-it-works).
```mermaid
---
title: The Operational Control Flow
---
flowchart TD
A["Monitoring Platforms
(Datadog, Splunk)"] -->|1. Detect| B("Paging & Alerting
(PagerDuty)")
B -->|2. Mobilize| C["Impact Assessment
(Slack, Jeli)"]
C -->|3a. Declare State| D{"Operational State
Control Plane (RuntimeHQ)"}
C -.->|3b. Diagnose & Fix| H["Engineering Workflow
Root Cause Investigation"]
D -->|4. Distribute State| E[Web Application]
D -->|4. Distribute State| F[Mobile App]
style D fill:#0ea5a9,stroke:#0f766e,stroke-width:2px,color:#fff
style H stroke-dasharray: 5 5
```
*Figure: The complete operational control flow, illustrating the parallel tracks of human engineering workflow (root cause investigation) and the deterministic machine reaction (protecting the customer).*
### How does this affect my existing incident management tools like incident.io or PagerDuty?
It complements them. Those tools manage the human workflows (Steps 2 and 3), while the Operational State Control Plane manages the application workflow (Steps 4 and 5).
## Architecture Principles
When building out your incident runbook and evaluating your operational infrastructure, consider these core principles:
- **Separate Detection from Mitigation:** Do not couple the systems that detect infrastructure faults with the systems that control application behavior. A telemetry anomaly is a signal, whereas an operational state change is a human-verified decision.
- **Protect the User Experience First:** Mitigating customer friction should happen in parallel with, not after, the root cause investigation. Your runbook must explicitly dictate how to gracefully degrade the application instantly.
- **Iteratively Narrow the Impact Scope:** As responders learn more about the incident, the runbook should require the Incident Commander to dynamically narrow the degradation (e.g., moving from a global outage banner to disabling only the specific 'checkout' capability).
- **Never Block Customer Requests:** The control plane must never sit in the critical path. Applications should asynchronously poll for updates and continue serving users using the locally cached Operational State, ensuring application performance is never degraded.
- **Isolate the Control Plane Infrastructure:** The system you use to declare and distribute Operational State must reside on completely separate infrastructure from your primary application to avoid shared fate during a catastrophic outage.
- **Centralized Visibility & Access:** During a Sev-1, the Incident Commander must have a single, unified view of the application's current state and a centralized interface to modify it, eliminating the need to coordinate manual changes across disparate teams.
RuntimeHQ was designed explicitly around these principles to serve as your dedicated engine for Steps 4 and 5.
## Conclusion: Upgrading Your Incident Runbook
When an incident strikes, your observability tools will tell you something is broken, and your paging tools will wake up the team. But while your engineers spend the next 35 minutes investigating the root cause, your application needs explicit direction.
Transitioning from a human-centric runbook to a complete 5-step Operational Control Flow ensures that your software gracefully degrades and communicates transparently with your customers, completely independent of the chaotic human debugging process.
### Key Takeaways
- Traditional incident ecosystems focus purely on detecting problems and managing humans, leaving a gap in application-level mitigation.
- The 5-Step Operational Control Flow bridges this gap by introducing Incident Declaration and Instant Application Response.
- Release State (Feature Delivery) and Operational State (Incident Response) are fundamentally different architectural disciplines requiring different tools.
- An Operational State Control Plane deterministically distributes state without impacting the critical request path.
- RuntimeHQ implements these architectural principles to seamlessly manage the final two steps of your incident runbook.
**[Book a Technical Discussion](#contact-section)** to evaluate how RuntimeHQ provides a dedicated Operational State Control Plane built for resilience.