Declaring Operational State
How to declare operational state and coordinate runtime behavior during disruptions.
Declaring Operational State
When a production system fails or dependencies degrade, declaring an operational state is the fastest way to communicate the condition to your applications and users.
Declaring an operational state initiates an active Incident record in RuntimeHQ. While incident response tools like PagerDuty or Opsgenie mobilize human responders and manage on-call rotas, the RuntimeHQ incident record coordinates machine behavior—publishing authoritative state to your applications so they can gracefully adapt their UI, shed traffic, and protect the customer experience.
How to Declare Operational State
Warning
Operational states declared in the Console or via the Control Plane API will immediately target the production environment of your applications. If you are testing your integration in lower environments or running disaster recovery drills, use the Non-Production Simulation feature from the specific Application Details page instead.
You can declare operational state either directly from the Console or programmatically via the Control Plane API:
1. From the Console
When operating from the Console, you can declare operational state from two locations:
- Global Incidents Page: Click Declare State and select the impacted applications.
- Application Details Page: Click Declare State from the Hero Section to automatically associate the state declaration with the current application.
2. Programmatically via Control Plane API
Operational state can also be declared programmatically outside the Console using the Control Plane API:
CreateIncidentAPI (control-plane-api/incidents/CreateIncident) — Programmatically trigger and declare operational state from automated monitoring alerts, on-call paging platforms (e.g., PagerDuty, Opsgenie), or custom orchestration pipelines.
Incident Configuration
When declaring operational state for an incident, you configure:
- Title: A concise summary of the disruption (e.g., "Stripe checkout latency spike").
- Operational State: The condition of the capability (
OutageorDegraded). - Impacted Capabilities: Choose whether the entire application is impacted, or only specific capabilities (e.g., just the
paymentsmodule). - Customer Message: (Optional) Provide a public-facing message that can be displayed within your application UI via our SDKs.
Managing the Incident Room
Once an incident is active, the Incident Room becomes the source of truth for the event. The incident is highly dynamic, allowing you to adapt to the evolving situation:
- State Transitions: An active incident can change its operational state to a higher severity (e.g., Degraded to Outage) or a lower severity at any time.
- Dynamic Scope: Impacted Capabilities and Applications can be added to the scope or removed at any time as the blast radius changes.
- Customer Message: The Customer Message can be continuously updated to follow incident progress.
- Operational Notes: Append internal, operational notes to maintain a chronological record of the investigation.
- Timeline: The timeline automatically tracks all major events (e.g., "Customer Message Updated", "Application Added to Incident").
- Resolution: Once the issue is mitigated, clicking Restore to Operational will immediately restore the application state back to
Operational.
Related Documentation
- Managing Applications — Application setup, capability management, and runtime keys overview.
- Non-Production Simulation — Safe peacetime testing and disaster recovery drills without impacting production traffic.
- Scheduling Maintenance — Proactively schedule and track maintenance windows.
- CreateIncident API — Programmatically configuring and declaring operational state via the Control Plane API.