# Why Outage Banners Don't Belong in Feature Flags
* **Author:** Sandeep
* **Published:** 2026-07-16
* **Description:** Feature flags are built for probabilistic product delivery, whereas incident response requires deterministic, global operational state activation.
* **Tags:** Incident Management, SRE, Architecture, Feature Flags, Operational State Control Plane
* **Canonical URL:** https://theruntimehq.com/insights/1-why-outage-banners-dont-belong-in-feature-flags
---
## In this article
You'll learn:
- Why feature flag platforms are excellent for product delivery but poor operational coordination
- Why customer-facing operational state should be modeled differently from release state
- Why capability targeting is fundamentally different from audience targeting
- What an Operational State Control Plane is
- When RuntimeHQ complements not replaces feature flag platforms
**The Bottom Line:** Feature flag platforms solve software delivery problems. Operational incidents require application coordination problems. Those are fundamentally different architectural concerns. Reusing feature flags for outages leads to fragmented schemas, an inability to natively target specific application capabilities, and severe cognitive load on Incident Commanders who must chase engineers during a Sev-1.
```mermaid
flowchart LR
A[Monitoring] --> B[Incident
Management]
B --> C[Operational State
Control Plane]
C --> D[Application
Behavior]
D --> E((Customer Experience))
style C fill:#0ea5a9,stroke:#0f766e,stroke-width:2px,color:#fff
```
## What is an Operational State Control Plane?
An [Operational State Control Plane](https://docs.theruntimehq.com/glossary#operational-state-control-plane) is a centralized system that distributes customer-facing operational state across applications during outages, degraded service, and maintenance.
Unlike feature flag platforms, which decide who receives a feature, an Operational State Control Plane decides how applications should behave during operational events.
## What is Operational State?
[Operational State](https://docs.theruntimehq.com/glossary#operational-state) represents the current health of an application or capability.
Examples include:
- Operational
- Degraded
- Outage
- Maintenance
Applications consume Operational State to determine how they should behave.
## The "Quick Fix" That Becomes Operational Debt
Using feature flags for outage banners is an understandable decision. Most organizations already have LaunchDarkly, Unleash, or another feature flag platform, so adding a `show-outage-banner` toggle feels like the fastest solution.
While this workaround functions adequately for a single application MVP, relying on feature toggles for emergency communication becomes a massive operational debt as an organization scales to multiple customer-facing applications (such as web frontends, mobile applications, and APIs). According to recent industry benchmarks from Splunk and Cisco, the average cost of enterprise downtime now hovers around **$15,000 per minute**-with 41% of large enterprises reporting hourly losses between $1 million and $5 million, according to the [ITIC 2024 Cost of Downtime Report](https://itic-corp.com/itic-2024-hourly-cost-of-downtime-report/). During these high-pressure windows, incident commanders don't have time to navigate disjointed product deployment tools; mitigation infrastructure must be purpose-built to reduce cognitive load and MTTR.
To be clear, feature flags are the exact right use case for experimentation, gradual feature rollouts, and A/B testing-they excel at product delivery. But when repurposed for outages or planned maintenance, you are fundamentally forcing an incident management workflow into a software delivery tool.
## Schema Drift and the Missing Operational Standard
Feature flags inherently lack a dedicated operational schema. Because they are designed as generic key-value stores or boolean toggles, every engineering team implements them differently during an outage:
- **Team A (Web)**: Creates an `is-outage` boolean flag.
- **Team B (Mobile)**: Creates an `outage-banner-text` JSON string flag.
- **Team C (API)**: Hardcodes the banner logic and uses a generic `hide-ui` toggle.
The lack of a dedicated operational schema becomes a genuine challenge when different teams start using it differently. When a global incident occurs, there is no standardized way to push a consistent, organization-wide state. For a deep dive into how toggles should be classified and why release toggles shouldn't be mixed with ops toggles, review Martin Fowler's canonical definitions on [Feature Toggles](https://martinfowler.com/articles/feature-toggles.html).
Expanding on that concept, here is a breakdown of how generic feature flag platforms compare to purpose-built operational control planes:
| Criteria | Feature Flag Platforms | Operational State Control Planes |
| :--- | :--- | :--- |
| **Primary Users** | Product Engineers & Release Managers | SREs & Incident Commanders |
| **Runtime Ownership** | Individual engineering teams | Centralized operational authority |
| **Primary Use Case** | A/B testing & gradual feature rollouts | Operational response during outages, degraded service & maintenance |
| **Core Question Answered** | Who should receive this feature? | How should applications behave during operational events? |
| **Targeting Scope** | Audience targeting (User segments, cohorts) | Capability targeting (Application Capabilities, Global) |
| **Data Model** | Generic key-value pairs or booleans | Native operational payload (state, messaging) |
| **Cross-App Consistency**| Independent application implementations | Centralized operational state distributed across applications |
| **Customer Copy** | Application-specific implementation | Centralized customer messaging distributed with operational state |
| **Postmortem Support** | Fragmented git history or flag logs | Operational Timeline ("What happened?") |
| **Audit Logs** | Feature flag configuration changes | Operational state and messaging changes |
| **Redeployment Required** | Often no, but requires application-specific implementation | No redeployment to change operational state or messaging |
## Why Capability Targeting Matters
Modern degradation isn't just "site up" or "site down." It requires targeting specific *capabilities*. If the payment gateway fails, you want to degrade the "payments" capability while leaving the "search" and "catalog" functionalities fully operational.
Targeting application capabilities becomes extremely complex with non-native solutions. Trying to map application capabilities using generic feature flags designed for audience targeting results in a tangled web of nested rules and brittle logic across different codebases. By contrast, RuntimeHQ natively supports *impact scope*, also known as an Application Capability. An Application Capability represents a discrete business function within an application that can have its own operational state (e.g., Payments, Search, Claims, or Notifications).
Crucially, RuntimeHQ supports resolving operational state at the capability level even when multiple incidents overlap. While one incident might force the Payments capability into an `OUTAGE`, a completely separate incident could simultaneously place the Search capability in a `DEGRADED` state, while all remaining capabilities stay fully `OPERATIONAL`. For a technical deep dive on how this is calculated globally, refer to the [Deterministic State Resolution](https://docs.theruntimehq.com/architecture#deterministic-state-resolution) documentation. Deterministic State Resolution is one of the core architectural concepts behind RuntimeHQ.
```mermaid
flowchart TD
subgraph Events [Active Events]
E1[Payment API Latency
Target: Payments
Status: Degraded]
E2[Card tokenization failure
Target: Payments
Status: Outage]
E3[Search Index Upgrade
Target: Search
Status: Maintenance]
end
Engine((RuntimeHQ
Engine))
subgraph CapRes [1. Capability-Level Resolution]
C1[Payments Capability
Effective: Outage]
C2[Search Capability
Effective: Maintenance]
end
subgraph AppRes [2. Application-Level Resolution]
App[Global Application
Effective: Outage]
end
E1 --> Engine
E2 --> Engine
E3 --> Engine
Engine -->|Outage overrides Degraded| C1
Engine --> C2
C1 -->|Most severe inherited| App
C2 --> App
style Engine fill:#0ea5a9,stroke:#0f766e,stroke-width:2px,color:#fff
```
_Architecture flow: The Operational Control Engine deterministically resolves conflicting states (e.g., Incident A vs. Maintenance Window) at the capability level before pushing the final effective state to the edge._
## The Cognitive Load on Incident Commanders
During a Sev-1 incident, Incident Commanders (ICs) should be coordinating mitigation, not acting as project managers. According to Atlassian's State of Incident Management report, it already takes an average of **27 minutes** just to assemble the necessary response teams. With feature flags acting as operational toggles, the IC loses even more time coordinating application owners or engineers on Slack to manually toggle a banner or update messaging for their specific services. For more context on managing cognitive load and coordination during incident response, refer to the [Google SRE Book](https://sre.google/sre-book/incident-document/).
Furthermore, when ICs or engineers *do* log into a feature flag platform during an outage, they are immediately confronted with a user interface optimized for product marketing-not incident response. They are forced to navigate through irrelevant distractions like Rulesets, Hypotheses, and Traffic Allocation sliders just to update a simple operational state. Every extra click and cognitive hurdle during a Sev-1 directly inflates MTTR (Mean Time to Resolution) and increases the risk of human error.
This human coordination nightmare and UI friction guarantees inconsistent customer messaging across mobile and web platforms. In contrast, by providing a purpose-built incident management interface, RuntimeHQ brings cross-app consistency instantly while keeping cognitive load to an absolute minimum.
## Establishing an Operational State Control Plane
An **Operational State Control Plane** (like RuntimeHQ) solves this by providing a unified, strict operational schema. The IC activates the state *once* via the [Console](https://console.theruntimehq.com/) or by other integration adapters, and the control engine computes and propagates the capability-specific state to all apps.
Unlike a simple boolean flag, the application consumes a structurally rich payload designed explicitly for graceful degradation. Here is a JSON snippet demonstrating what a native capability-targeting schema looks like, eliminating guesswork for client applications:
### Example Operational State Payload
```json
{
"state": "RUNTIME_STATE_DEGRADED",
"message": "Payment processing is delayed to higher latency from service provider",
"capabilityStates": [
{
"capabilityName": "payments",
"state": "RUNTIME_STATE_DEGRADED",
"message": "Payment processing is delayed to higher latency from service provider."
},
{
"capabilityName": "search",
"state": "RUNTIME_STATE_OPERATIONAL"
}
],
"updatedAt": "2026-06-05T12:09:32.611Z",
"version": "7"
}
```
By leveraging this native schema, developers can cleanly decouple product delivery from operational resilience. To see exactly how this integrates with your frontend, review our [Documentation](https://docs.theruntimehq.com/runtime-api/edge-api/GetRuntimeState).
Beyond incident mitigation, this centralized architecture fundamentally improves post-incident reviews, especially when preparing Correction of Error (CoE) reports. While feature flagging platforms absolutely maintain their own audit logs, those logs are restricted to generic toggle events, making it difficult to reconstruct a cohesive incident narrative. RuntimeHQ, however, provides a dedicated [Operational Timeline](https://docs.theruntimehq.com/glossary#operational-timeline) that explicitly answers *"What happened during this incident?"* alongside a tamper-evident **Audit Log** that captures exact operational actions-such as when an incident was created, when a capability state was changed, or when a customer message was updated. This provides undeniable clarity and traceability for postmortems.
## Frequently Asked Questions
1. **Can I use feature flags for incident management?**
Yes, but it introduces operational debt. Product flags lack a standardized schema, meaning different teams implement outage banners inconsistently across your stack.
2. **What is the difference between progressive delivery and operational state?**
Progressive delivery tests code on subsets of users. Operational state defines the global health of the application and its specific capabilities during incidents.
3. **Why is targeting application capabilities difficult with feature flags?**
Feature flags rely on generic booleans or key-value pairs. Modeling complex impact scopes-like disabling 'payments' while keeping 'search' active-requires writing fragile, custom routing logic instead of relying on a native operational payload.
4. **How does an Operational State Control Plane reduce MTTR?**
By giving Incident Commanders a single centralized console to activate a standardized schema across all microservices, eliminating the need to chase individual application owners or engineers to toggle their respective banners.
## Conclusion: When Should You Use RuntimeHQ?
Use Feature Flags when:
- Rolling out software
- Running experiments
- Testing hypotheses
Use an Operational State Control Plane when:
- Coordinating outages
- Activating maintenance
- Gracefully degrading capabilities
- Synchronizing customer messaging
- Keeping multiple applications operationally aligned
The two approaches solve different problems and complement each other.
If your team is currently attempting to force incident communication through software delivery tools, it is time to upgrade your infrastructure. **[Book a Technical Discussion](#contact-section)** to evaluate how RuntimeHQ complements feature flag platforms by providing a dedicated Operational State Control Plane for customer-facing operational events.