Runtime-State API Availability
Availability Target
• Runtime-state API target availability: 99.9% monthly uptime
Scope
Availability targets apply strictly to edge resolved outputs:
- Runtime-state API endpoints
- Runtime-state fetch operations
- SDK runtime-state resolution requests
Exclusions
Uptime calculations exclude:
- Customer application-level outages
- Third-party cloud infrastructure outages outside RuntimeHQ control
- Scheduled, communicated maintenance windows
- Global internet or client DNS connectivity failures
Incident Response Objectives
Incident Acknowledgement
- Critical operational incidents affecting edge delivery are acknowledged internally as quickly as possible after automated detection logs trigger.
Customer Communications
- Customer-impacting RuntimeHQ incidents are communicated through verified official status channels.
- Major operational disruptions are updated periodically until final mitigation and resolution reports are compiled.
Runtime-State Integrity Priority
During active internal platform incidents, we prioritize SRE mitigations in this sequence:
Planned Maintenance Policy
Maintenance Scheduling
- Planned maintenance is scheduled during low-traffic operational windows to minimize potential integration impacts.
Notice Target
- Advance notice is provided for planned maintenance expected to impact organizational dashboard controls.
Notifications Content
Maintenance alerts outline:
Emergency Maintenance
- Performed immediately without notice when critical operational stability, system availability, or network security requires urgent action.
Support Response Targets
Operational support requests are actively monitored during standard business hours. Initial response targets are managed dynamically by priority:
Core edge state delivery degradations, API outages, or administrative lockout events.
Scheduled maintenance scheduling problems, targeting issues, or sandbox credential bugs.
Integration SDK questions, schema designs, account administration, or billing inquiries.
Incident Communication
We provide calm, factual status metrics without marketing adjectives, ensuring clear SRE impact visibility.
Updates detail affected applications, operational impacts, active mitigations, and expected timing for the next status sweep.
Major platform incidents undergo a detailed post-incident review to improve recovery procedures and edge reliability.
Operational Retention
Operational logs are preserved to support incident visibility and SRE timeline reconstructions.
Archived application configs and active keys are preserved internally to safeguard audit trace integrity.
Audit history databases are append-only to prevent tampering or accidental history pruning during active reviews.
Service Scope Limits
To maintain absolute focus on edge reliability, RuntimeHQ strictly does not provide general operations tooling:
RuntimeHQ strictly focuses on propagating runtime state variables securely at the Edge.
Service Commitments Evolve
Operational objectives and support commitments are expected to evolve alongside infrastructure maturity, enterprise adoption scales, and customer operational requirements. Updated commitments will be communicated through official RuntimeHQ channels.
Service Commitments FAQ
Review key answers regarding uptime targets, maintenance notification windows, and API availability scopes.
What uptime target does RuntimeHQ provide?
How quickly does RuntimeHQ communicate operational incidents?
Does RuntimeHQ provide planned maintenance notifications?
Does RuntimeHQ guarantee uninterrupted service?
How are RuntimeHQ outages communicated?
Does RuntimeHQ provide enterprise SLAs?
Are API rate limits part of the SLA?
Does RuntimeHQ provide disaster recovery protections?
Evaluate high-availability operational runtime states
Connect your platforms with reliable edge state controls. Set up a dedicated technical discussion to discuss regional architectures, replication metrics, and SLA coverage.
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