Non-Production Simulation

A production incident is the worst time to discover how your applications react to operational state changes. Non-Production Simulation provides engineering teams with a safe, controlled mechanism to simulate outages, degraded capabilities, and maintenance windows during peacetime.

By overriding runtime state exclusively for non-production environments, you can validate client UI fallbacks, test SDK integrations, and run disaster recovery drills without touching production traffic or impacting real customers.

Peacetime Verification Philosophy

Operational resilience requires verifying two distinct concerns:

1. Operational Condition (Control Plane): Declaring what state a capability or application is in (Operational, Degraded, Outage, or Maintenance) along with the authorized operational message.
2. Application Behavior (Application Runtime): How your application responds to that condition (e.g., rendering an inline banner, disabling checkout buttons, or offering alternative workflows).

Simulation decouples these concerns for testing. You use the RuntimeHQ Console to declare a simulated condition, allowing your staging, QA, and local development applications to independently verify their behavioral responses.

Dual-Key Isolation Architecture

RuntimeHQ guarantees strict blast-radius isolation between production and testing environments using dedicated Runtime Keys:

• Production Key (rt_prod_xxxx): Configured in production application builds. SDKs using this key receive resolved runtime state computed exclusively from active incidents and scheduled maintenance windows.
• Non-Production Key (rt_test_xxxx): Configured in non-production environments. SDKs using this key receive the simulated operational state configured in the Console.

Because state resolution and edge distribution artifacts are strictly partitioned by runtime key, updating a simulation state in the Console has zero effect on production state artifacts or live user traffic.

Configuring Simulation in the Console

You can configure and update the simulated state for any application directly from the Console UI:

1. Navigate to Applications from the primary navigation and select your application.
2. Click the Integration tab.
3. Locate the Non-Production Simulation State panel.
4. Click Simulate Runtime State to open the configuration modal.

Simulation Parameters

Within the modal, configure the following properties:

• Target State: Select the operational state to simulate:
  • Operational: Normal baseline operations (default).
  • Degraded: Partial capability impairment or degraded performance.
  • Outage: Complete service or capability unavailability.
  • Maintenance: Planned downtime or scheduled maintenance testing.
• Simulated Customer Message: The authoritative operational message distributed to client applications. Pre-populated default templates are provided for each state, or you can supply custom copy (e.g., "Payment gateway experiencing elevated latency; credit card checkout temporarily restricted.").
• Affected Capabilities: Control the blast radius of the simulation:
  • Full Application Impact: Leave all capabilities unchecked to mark the entire application as impacted.
  • Capability Targeting: Expand the capabilities drawer and select specific capabilities (e.g., checkout.card-processing) to test targeted degradation while leaving the remainder of the application operational.

Click Simulate State to apply the configuration. The control plane generates the updated non-production state artifact and distributes it to the edge cache.

Inspecting Active Simulation

Once configured, the Non-Production Simulation State panel displays:

• Status Indicator: A color-coded severity badge reflecting the current simulated state (Operational, Degraded, Outage, or Maintenance).
• Affected Capabilities: Badges listing all capabilities currently targeted by the simulation.
• Customer Message: The active operational guidance string distributed to SDKs.
• Last Simulated: The exact timestamp when the simulation was last modified.

Verifying the Edge State via cURL

Before testing client applications, you can directly inspect the resolved state payload at the edge using cURL. This verifies that the distribution layer has resolved your simulation without relying on SDK code:

curl -X GET \
  -H "Accept: application/json" \
  https://edge.theruntimehq.com/v1/{NON_PRODUCTION_RUNTIME_KEY}.json

Example Response Payload

{
  "runtimeState": {
    "applicationId": "app_019e8625-c3e4-7ab0-843e-730054f4efbe",
    "state": "RUNTIME_STATE_DEGRADED",
    "message": "Card processing is temporarily delayed. Alternative payment methods remain active.",
    "capabilityStates": [
      {
        "capabilityName": "payments.card-processing",
        "state": "RUNTIME_STATE_DEGRADED",
        "message": "Card processing is temporarily delayed. Alternative payment methods remain active."
      },
      {
        "capabilityName": "payments.digital-wallet",
        "state": "RUNTIME_STATE_OPERATIONAL",
        "message": "All systems operational"
      }
    ],
    "updatedAt": "2026-09-19T13:30:00.611Z",
    "version": "12"
  }
}

For full endpoint specifications and caching headers, refer to the Edge API Reference.

Peacetime Drill Scenarios

Use Non-Production Simulation to conduct structured verification drills across your engineering and QA teams:

1. Full Outage Drill

• Setup: Set Target State to Outage with all capabilities affected.
• Verification Goals:
  • Verify that the application renders a top-level outage announcement with the configured operational message.
  • Verify that critical write actions (such as form submissions or checkouts) are disabled gracefully.
  • Confirm that read-only navigation (such as documentation, help centers, or public content) remains accessible if intended.

2. Scoped Capability Degradation Drill

• Setup: Set Target State to Degraded and select a single capability (e.g., reports.export or payments.card-processing).
• Verification Goals:
  • Verify that the specific capability displays an inline warning or falls back to an alternate path (e.g., offering ACH or digital wallet options).
  • Confirm that all unaffected capabilities continue functioning without interruption or false error warnings.
  • Ensure that the application distinguishes clearly between Degraded and Outage experiences rather than collapsing them into an identical failure screen.

3. Scheduled Maintenance Drill

• Setup: Set Target State to Maintenance with an operational message detailing the maintenance scope.
• Verification Goals:
  • Verify that users see a clear maintenance notice explaining that background updates are underway.
  • Verify that background data-fetching mechanisms pause or fail gracefully without generating unnecessary client-side error logs.

4. Recovery & Restoration Verification

• Setup: Revert the simulated state back to Operational.
• Verification Goals:
  • Verify that consuming applications automatically detect state recovery on their subsequent background polling refresh.
  • Confirm that degraded UI components, disabled buttons, and warning banners clear automatically without requiring manual page reloads or service restarts.

Resetting Simulation State

When testing or drills are complete, always reset the application state to return non-production environments to their baseline:

1. Open the Integration tab on the Application Details page.
2. Click Simulate Runtime State.
3. Select Operational from the Target State dropdown.
4. Click Simulate State.

Once saved, the edge distribution layer immediately distributes the Operational state, clearing any previous capability targeting and customer messages for clients using the Non-Production Key.

Related Documentation

• Managing Applications — Application setup, capability management, and runtime keys overview.
• Runtime Keys — Key security, environment scoping, and distribution mechanics.
• Declaring Incidents — Declaring live incidents for production environments.
• React SDK Integration — Consuming runtime state and hooks in React applications.
• JavaScript SDK Integration — Consuming runtime state in browser, Node.js, and serverless environments.
• SimulateApplication API — Programmatically configuring simulation state via the Control Plane API.