System Architecture

RuntimeHQ provides a centralized Operational State Control Plane (OSCP) that enables engineering organizations to coordinate application behavior across their entire Application Estate during incidents, maintenance windows, and degraded dependencies.

By decoupling operational state coordination from software release cycles and CI/CD pipelines, authorized operators can declare operational conditions and authorize operational messages without emergency code deployments. Consuming applications synchronously read local runtime state to execute coordinated graceful degradation, fallback workflows, or contextual customer communication.

Architectural Layers

RuntimeHQ operates on a strict physical and logical separation across three core architectural blocks:

• The Control Plane: Used for all configuration and mutation actions. This includes defining applications and their capabilities, declaring operational state, 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.
• Distribution Layer: Asynchronously propagates and edge-caches resolved operational state payloads globally. It physically and logically decouples control plane mutations from runtime reads, absorbing high-frequency client queries with zero impact on the control engine.
• The Runtime Plane: Embedded directly within consuming applications via Runtime SDKs or in-memory caches. It synchronizes state out-of-band from the distribution layer using Runtime API in the background, adding zero network latency to capability state check requests through local in-memory evaluation.

The diagram below details the internal component interaction across these layers:

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 State Engine deterministically resolves conflicting declarations at the capability level before publishing resolved state artifacts to the distribution layer.

Runtime State and the Capability State Matrix

Runtime state represents the computed, effective operational state of an application. This state is delivered to connected applications as a Capability State Matrix—a centralized architectural contract mapping each of the application's capabilities to its current health.

The platform classifies operational state into four canonical states:

• Operational: Capability functions normally with full availability and performance.
• Degraded: Capability is partially impaired, operating with reduced performance, or utilizing a degraded dependency.
• Outage: Capability is completely unavailable or non-functional.
• Maintenance: Capability is undergoing planned maintenance under predefined operational rules.

How It Works

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