Frequently Asked Questions

No, and that's intentional. Every organization has its own observability stack. RuntimeHQ consumes the operational decision after the team decides, "Yes, Search is degraded," or "Payments are down." RuntimeHQ then propagates the operational state to applications and applications respond to it.

That's the closest existing comparison, but RuntimeHQ intentionally stops before feature targeting or user targeting. RuntimeHQ only manages operational states like Outage, Degraded Service and Maintenance. The application decides how to respond. We're not deciding which users see which features; we're coordinating operational response.

Status pages inform users externally. RuntimeHQ changes application behavior. Those are complementary. A status page might say "Search is degraded," while RuntimeHQ enables the application to show the same message, disable only the affected capability, or gracefully degrade the experience.

Monitoring tells you something is wrong. RuntimeHQ starts after your team has decided what the operational state is. It's the bridge between incident response and application behavior.

This is where our architecture shines. RuntimeHQ doesn't sit in the request path. Our SDKs refresh state asynchronously in the background. Runtime state is served from edge cache with short stale-while-revalidate caching. Applications simply read locally available state, so there is no runtime API dependency and no impact on request latency.

Your applications keep running exactly as they were. Because RuntimeHQ is never in your critical request path, our SDKs will simply fall back to the last successfully fetched state. Furthermore, our delivery architecture is built for extreme resilience. Computed states are pushed to highly-durable cloud object storage and distributed globally via a multi-vendor CDN edge cache. Even if our primary control plane goes down, your edge-cached operational states remain highly available.

Absolutely. That's actually the point. RuntimeHQ distributes the operational state. Each application decides how to respond. One application might hide a capability. Another might disable it. Another might keep it available but show a warning. Same state. Different behavior.

Tools like incident.io and PagerDuty manage the human workflows of incident response—alerting on-call engineers, coordinating Slack channels, and tracking resolution timelines. RuntimeHQ manages the application behavior side of the incident. They are completely complementary. You declare and manage the human response process in incident.io, and RuntimeHQ automatically translates that declared state down to your frontend applications so they can gracefully degrade.

Applications register their capabilities once through console. During runtime they simply ask, "What's the current state of Search?" or "What's the current state of AI Assistant?" and decide how to behave. We have open source SDKs for React and other languages to make the integration easy and reliable.

No. Outage is just one state. We also support degraded service and planned maintenance. Furthermore, when there are multiple incidents going on simultaneously, the Operational State Control Engine evaluates the highest severity for each affected capability, and your application simply receives the simplified, resolved state through our SDKs.

No. We do not process or ingest any logs to run intelligence on top of them to suggest or decide incidents. An incident can be started manually from our Console by an incident commander, or triggered programmatically by consuming our APIs within your organization's existing monitoring and observability tools.

RuntimeHQ SaaS infrastructure is hosted on Amazon Web Services (AWS), by default in the United States unless otherwise agreed. Regional hosting flexibility is available for enterprise customers during onboarding. We encrypt data at rest and during transit.

At the moment, we only support email and password-based login with a 2FA code. SSO support is planned for future phases, including Microsoft and Okta-based authentication support.

StatusGator helps you monitor when third-party dependencies go down. RuntimeHQ is what you use to control your application once you know it's down. While an aggregator might tell you an API is failing, RuntimeHQ provides the SDK layer you use to instantly push a 'degraded state' to your frontend—safely disabling buttons and showing warning banners without waiting for a developer deployment or hacking feature flags. Essentially, status aggregators are the bulletin board outside the building; RuntimeHQ controls the emergency lights inside the application.

RuntimeHQ is an early-stage infrastructure product. While we have not yet completed SOC 2 or ISO 27001 certification, the platform has been designed with enterprise security principles from day one. We are happy to complete security questionnaires and discuss our architecture in detail during evaluation.