Console

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:

  • CreateIncident API (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 (Outage or Degraded).
  • Impacted Capabilities: Choose whether the entire application is impacted, or only specific capabilities (e.g., just the payments module).
  • 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.

On this page