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:
Default state. All systems green.
Partial delays or component degradation.
Core systems down or unavailable.
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.
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
npm install @theruntimehq/jsReact SDK
npm install @theruntimehq/react @theruntimehq/jsInitialize 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:
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:
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:
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:
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:
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.
https://edge.theruntimehq.com/runtimehq/v1/public/YOUR_RUNTIME_KEYAPI Raw Output Payload
{
"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 Name | Type | Description |
|---|---|---|
| applicationId | string | Unique identifier for the application. |
| state | string | Current operational indicator: operational, degraded, outage, or maintenance prefixed with RUNTIME_STATE_ prefix. |
| message | string | Customer facing message that is set for the running incident or maintenance window. |
| source | string | Identifies what triggered the state shift: incident or maintenance. Prefixed by RUNTIME_STATE_SOURCE_. |
| startedAt | string | UTC timestamp representing when the state transition occurred (ISO 8601 string format). |
| endedAt | string | null | UTC 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.
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:
Implement client polling every 30 to 60 seconds. This sustains optimal responsiveness without imposing undue networking overhead.
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.
- Preserve Last State: Retain the last successfully resolved runtime state on client devices briefly during brief timeout events.
- Graceful Recovery: Default silently to
operationalstate 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
- Start Incident within the control console.
- Select runtime state target (
degraded/outage). - Select impacted applications or global zones.
- Configure & review the customer-facing message update.
- Activate runtime state to trigger real-time SDK propagation.
Maintenance Workflow
- Schedule Maintenance Window detailing dates & target hours.
- Select impacted applications or components.
- Configure maintenance message detailing scope.
- 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:
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.
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