Operational State Control Engine

RuntimeHQ provides centralized operational runtime-state infrastructure specifically engineered for customer-facing web and mobile applications during incidents, maintenance events, and partial degraded outages.

By decoupling public banners and circuit fallbacks from standard databases and CI/CD redeploy pipelines, Incident Commanders can inject mitigation banners, routing controls, or safe system fallbacks in real-time.

The Two Planes

RuntimeHQ operates on a strict physical and logical separation between management operations and state delivery:

• The Control Plane: Used for all configuration and mutation actions. This includes defining applications and their capabilities, creating incidents, managing the incident lifecycle, and scheduling maintenance windows. All actions and mutations happen here, either manually through the Console UI or programmatically by consuming our Control Plane API.
• The Runtime Plane: Used strictly to distribute the resolved operational state of applications and their capabilities. It consists of a low-latency, edge-cached REST API endpoint designed for read-only consumption. This is the exact same endpoint consumed inside our Runtime SDKs, and can also be queried directly via the Runtime API.

Core Entities

Applications, Application Capabilities, Incidents, and Maintenance Windows form the foundation of RuntimeHQ. For a detailed breakdown of these objects, read the Core Entities page.

Deterministic State Resolution

The control engine dynamically computes the effective state for each application whenever an incident is created, updated, or a maintenance window is activated.

Because operational events frequently overlap, RuntimeHQ resolves conflicts deterministically:

1. Capability-Level Resolution: If multiple events target the same capability, the engine applies the most severe operational state (e.g., an Outage overrides a Degraded state).
2. Application-Level Resolution: Once all individual capabilities are calculated, the overall application inherits the highest severity state from across its capabilities. For example, if an application has ten capabilities and even one is in an Outage, the global application state reflects that maximum impact.

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.

Runtime State

Runtime state represents the computed, effective operational state of an application. The platform categorizes operations into four distinct values:

• Operational (Default state. All systems healthy.)
• Degraded (Partial delays or component degradation.)
• Outage (Core systems down or unavailable.)
• Maintenance (Planned service disruption window.)

How It Works

To learn how RuntimeHQ propagates operational state from incident declaration down to client application response, read the dedicated How It Works page.