Uptime targets, severity-based response times, and automatic service credits for each Innovexus tier. The SLA is the same for every customer at a given tier — no enterprise-only carveouts, no per-deal renegotiation.
Uptime is measured against the per-tenant Innovexus pod control plane availability — the API the customer's engineers and automation depend on. Measurement is calendar-month-based, computed from synthetic monitoring checks running every 60 seconds against the customer pod from outside the hosting infrastructure.
P1 — Production pod is fully unavailable, or privileged sessions cannot be brokered. Affects all customer engineers.
P2 — Material degradation: a major feature subset is non-functional, or single-region failover is required.
P3 / P4 — Minor degradations, cosmetic issues, or feature-request-class items. Best-effort response; no SLA target.
The SLA does not cover downtime caused by: (1) scheduled maintenance announced at least 48 hours in advance; (2) force majeure or third-party hosting infrastructure failures outside Innovexus's control (the hosting partner's SLA applies in that scope); (3) customer-initiated misconfigurations; (4) usage that materially exceeds documented tier limits; (5) issues caused by integrations or APIs operated by the customer or third parties not under Innovexus's contract.
Service credits are calculated automatically based on synthetic monitoring data. Customers receive a credit notification within 7 days of month-end if the SLA threshold was missed. Credits apply to the next billing cycle and are capped at one month of service. No retroactive claims past 30 days. Credits are non-cashable.
The Innovexus SLA above applies to the application layer Innovexus operates. Underlying hosting availability is governed by the hosting partner's SLA (currently RunPod Secure Cloud). For incidents rooted in the hosting partner's infrastructure, credits flow from Innovexus's SLA above; we do not pass-through hosting-partner disputes to the customer.
Public status page: shipped at /status. Reports live component health derived from the hosting verification API. External multi-region synthetic uptime pings (60-second cadence from outside the hosting infrastructure) are still on the roadmap — today, real-time degradations are communicated to active customers via Slack and email.
Multi-region uptime targets: [TBD for Enterprise] — Multi-region failover is configured per Enterprise customer at provisioning time. The SLA targets above apply to single-region availability; multi-region targets are negotiated based on the specific region pair.
The published SLA is the same for every customer at the relevant tier. If your procurement requires custom uptime targets, regional residency for measurement, or specific carveout language, that conversation lives at the Enterprise tier.