Operational Documentation

Developer Documentation

Integrate RuntimeHQ SDKs and REST APIs into your application stack to handle live runtime state, active outages, degraded behaviors, and maintenance windows.

✓ JavaScript & React SDKs✓ Low-latency edge REST APIs✓ Isolated Testing Environments✓ Graceful SRE Fallbacks

RuntimeHQ Documentation

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.

Core Concepts

1. 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 green.

degraded

Partial delays or component degradation.

outage

Core systems down or unavailable.

maintenance

Planned service disruption window.

2. Runtime State Engine

The RuntimeHQ propagation engine determines live states globally by evaluating active incidents, scheduled maintenance policies, and runtime targeting logic.

State Conflict Resolution: If multiple active rules apply (e.g., an application is undergoing scheduled maintenance, but a critical active outage incident is simultaneously activated), the most severe state always wins (outage > degraded > maintenance > operational).

Quick Start SDK Setup

We provide official SDKs for both raw JavaScript/TypeScript environments and React. Explore our source code and repositories on GitHub:

JavaScript / TypeScript SDK

bash
npm install @theruntimehq/js

React SDK

bash
npm install @theruntimehq/react @theruntimehq/js

Initialize JS/TS Client

Instantiate the RuntimeHQClient using your API runtime key (starts with rt_prod_ or rt_test_), which can be obtained for the respective application from the Console → Applications → Integration tab:

typescript
import { RuntimeHQClient } from "@theruntimehq/js";

const client = new RuntimeHQClient({
  runtimeKey: "rt_prod_xxxxx"
});

Initialize React Provider

Wrap your application root component with RuntimeHQProvider to enable context-based status checks throughout your components:

tsx
import { RuntimeHQProvider } from "@theruntimehq/react";

function App() {
  return (
    <RuntimeHQProvider 
      runtimeKey="rt_prod_xxxxx" 
      intervalSeconds={15}
    >
      <YourComponents />
    </RuntimeHQProvider>
  );
}

JS / TS SDK Integration Example

Query the runtime status directly using standard JavaScript/TypeScript. The SDK returns typed status indicators and handles local fallback caching under the hood:

typescript
import { RuntimeHQClient } from "@theruntimehq/js";

const client = new RuntimeHQClient({
  runtimeKey: "rt_prod_xxxxx"
});

async function checkStatus() {
  try {
    const runtime = await client.getRuntime();
    if (runtime.state !== "OPERATIONAL") {
      showBanner(runtime.message);
    }
  } catch (error) {
    console.error("Failed to fetch runtime status:", error);
  }
}

React SDK Integration Example

Consume dynamic state changes reactively within components. The hook automatically listens to state changes managed by the provider:

tsx
import { useRuntimeHQ, isOperational } from "@theruntimehq/react";

function RuntimeBanner() {
  const { runtime, loading, error } = useRuntimeHQ();

  if (loading || error) return null;
  if (!runtime || isOperational(runtime)) return null;

  return (
    <div className="runtime-banner">
      {runtime.message}
    </div>
  );
}

Next.js Integration Example

For maximum SEO indexability and server rendering compatibility, fetch dynamic state on the backend inside pre-rendering paths:

typescript
import { RuntimeHQClient } from "@theruntimehq/js";

const client = new RuntimeHQClient({
  runtimeKey: process.env.RUNTIMEHQ_RUNTIME_KEY!
});

export default async function Page() {
  const runtime = await client.getRuntime();

  return (
    <main>
      {runtime.state !== "OPERATIONAL" && (
        <div className="banner">
          ⚠️ {runtime.message}
        </div>
      )}
    </main>
  );
}

Runtime-State REST API Spec

For integrations outside the React/JS ecosystem, interact directly with our low-latency, edge-cached REST API endpoints. No authorization headers or credentials are required; simply include your API runtime key in the URL path.

GEThttps://edge.theruntimehq.com/runtimehq/v1/public/YOUR_RUNTIME_KEY

API Raw Output Payload

json
{
  "applicationId": "app_019e8625-c3e4-7ab0-843e-730054f4efbe",
  "state": "RUNTIME_STATE_OPERATIONAL",
  "message": "All systems operational",
  "sourceType": "RUNTIME_STATE_SOURCE_OPERATIONAL",
  "startedAt": "2026-06-05T12:09:32.609Z",
  "updatedAt": "2026-06-05T12:09:32.611Z"
}

Runtime State Schema Reference

The standard fields delivered inside all REST payloads:

Field NameTypeDescription
applicationIdstringUnique identifier for the application.
statestringCurrent operational indicator: operational, degraded, outage, or maintenance prefixed with RUNTIME_STATE_ prefix.
messagestringCustomer facing message that is set for the running incident or maintenance window.
sourcestringIdentifies what triggered the state shift: incident or maintenance. Prefixed by RUNTIME_STATE_SOURCE_.
startedAtstringUTC timestamp representing when the state transition occurred (ISO 8601 string format).
endedAtstring | nullUTC timestamp for scheduled termination. Returns null for incidents with open resolutions.

Environment-Specific Runtime Keys

RuntimeHQ strictly separates state metrics between production and non-production channels. These keys can be obtained for your respective application from the Console → Applications → Integration tab:

  • Production keys (rt_prod_*): Tied to live edge caches and incident control dashboards.
  • Non-production keys (rt_test_*): Dedicated for lower environments, testing banners, and preview workflows.
Isolation Constraint: Actions taken on non-production state pipelines never leak or affect live customer integrations, ensuring a safe zone for operational rehearsal events.

Runtime-State Testing

Validate banner rendering behaviors, customer warning layouts, and fallbacks by safely simulation testing runtime states.

By utilising non-production API keys or SDK dry-run profiles, engineering teams can conduct full disaster recovery rehearsals, verifying that public channels correctly present banners without triggering real incidents.

Recommended Caching Behavior

To balance propagation speed and edge API constraints, standard organizations should configure their SDK parameters based on:

Standard Applications

Implement client polling every 30 to 60 seconds. This sustains optimal responsiveness without imposing undue networking overhead.

Highly Critical Systems

Shorter intervals are supported. Edge CDN endpoints enforce very tight TTL controls to prevent stale state calculations.

Failure Handling Recommendations

RuntimeHQ SDK integrations are built to act as passive guardrails, ensuring that network interruptions or platform outages on the state control plane never impact your customers' core experiences.

Recommended Integration Fallback Strategy:
  • Preserve Last State: Retain the last successfully resolved runtime state on client devices briefly during brief timeout events.
  • Graceful Recovery: Default silently to operational state if endpoint response fails completely, ensuring standard users can proceed with core workflows unhindered.
  • Async Resolution: Never block page layout paint scripts waiting for runtime checks. SDKs execute asynchronously.

Operational Workflows

The standard operating procedures implemented within the RuntimeHQ control panel:

Incident Workflow

  1. Start Incident within the control console.
  2. Select runtime state target (degraded / outage).
  3. Select impacted applications or global zones.
  4. Configure & review the customer-facing message update.
  5. Activate runtime state to trigger real-time SDK propagation.

Maintenance Workflow

  1. Schedule Maintenance Window detailing dates & target hours.
  2. Select impacted applications or components.
  3. Configure maintenance message detailing scope.
  4. Activate window. State shifts automatically during target slots.

System Auditability

RuntimeHQ enforces immutable audit trail tracking. Every incident creation, state transition, message modification, and targeting configuration change is logged permanently. Incident commanders or SRE teams can inspect complete history trails to compile post-incident reviews or timelines.

Planned Documentation Expansion

Future documentation sections are scheduled to cover advanced operational architectures:

Webhooks SpecOkta SSO SetupRBAC Policies
Documentation Support

Need custom integration assistance?

Set up a dedicated session with our solutions engineering team. We are available to assist SREs with advanced React fallback rendering and custom replication topologies.

Book technical discussion

No sales pitch. Connect directly with our platform SREs to evaluate integration feasibility.

runtimehq-sre-shell
$ echo $SRE_EMAIL
Recommended Context

To help us prepare for our discussion, please share some context on your current outage banner workflow, such as:

  • Hardcoded banner deployments
  • Toggling CMS content manually
  • Editing feature flags during active incidents