SLAs & SLOs¶
Venturi separates customer AI traffic from Venturi serving-plane availability. The decision-time interceptor fails open for live AI requests; the serving-plane targets govern the dashboard, query API, and export surfaces.
Three terms, used precisely: an SLI is the measured indicator, an SLO is Venturi’s internal objective on that indicator, and an SLA is the contracted commitment attached to your support tier. The objective is always at least as strict as the commitment.
What 99.9 does and does not mean¶
The 99.9% serving-plane target applies to Venturi’s query and dashboard surface inside your dedicated tenant data plane: in your cloud when self-hosted, or in your contracted residency lane in SaaS mode. It does not describe the availability of your AI traffic, because the decision-time interceptor forwards a request unmodified when the index lookup, the event stream, or any other Venturi dependency behind it is slow, degraded, or unavailable. The Premium and Regulated support tiers step the serving-plane commitment up to 99.95%.
Proxy endpoint reachability¶
Fail-open covers the Venturi dependencies behind the interceptor. It cannot
cover the endpoint your application sends requests to. With the
drop-in proxy, your SDK’s base URL points at the
proxy (https:// on the SaaS tier, or your
own instance host when self-hosted), so the proxy endpoint’s own reachability is
on your request path: a request that cannot reach the proxy is never forwarded.
The serving-availability commitments on this page cover the dashboard, query
API, and exports; none of them covers the proxy endpoint. Tenant admission also
rejects a provider key that is not registered to your tenant before anything is
forwarded (see Tenant admission).
For a workload that cannot accept the proxy endpoint as a dependency:
- configure client-side failover that retries a request against the provider’s direct base URL when the proxy cannot be reached; or
- capture request-level metadata through the Ingestion API or a connector instead. Neither sits between your application and the provider.
Service objectives¶
These objectives apply to every tenant. Where a support tier carries a stricter commitment, Venturi’s objective for that tenant is at least as strict as the commitment.
| Objective | Target | Scope |
|---|---|---|
| Decision-time interceptor latency | 50 ms P99 end-to-end; 15 ms internal | Decision-time observation path. A cooperative timeout against a cumulative deadline forwards the request unmodified on breach. |
| Asynchronous processor latency | 100 ms P99 | Attribution processing after the request path. |
| Stage B timeout | 20 ms wall-clock, inside the processor’s 100 ms P99 budget | Stage B (trained edge-existence inference) runs in the asynchronous processor; on breach the heuristic baseline answers and attribution processing keeps flowing. Customer traffic is unaffected. |
| Serving availability | 99.9% over a rolling 28-day window; 99.95% for Premium and Regulated tenants | Dashboard, query API, and exports. |
| Index freshness | P99 at or below 90 seconds | The materialized attribution index. |
| Attribution coverage | At or above 0.95 | Share of capturable AI usage that resolves at or above the confidence floor. |
| Reconciliation latency | At or below 24 hours | Reconciled-actual spend; the billable basis at coper >= 0.80. |
| Notification delivery | P95 at or below 30 seconds | Critical in-app, Slack, and Microsoft Teams notifications. Email and signed-webhook notices carry no delivery-latency objective. |
| Recovery objectives | RPO at or below 15 minutes; RTO at or below 1 hour | Tenant attribution stores and event logs. See Disaster recovery. |
The 50 ms interceptor figure is a P99 objective measured end to end. Cooperative timeouts bound internal steps against a cumulative monotonic deadline; an exception or timeout forwards the admitted request unmodified. The objective does not assert an externally enforced wall-clock ceiling for every individual request.
Commitments by support tier¶
Your order form names the support tier you hold; it is the commercial authority, and any customer-specific commitment beyond this table is written into it. This page is the technical authority for what each tier means.
The coverage floor below is the attribution-coverage floor; acknowledgment refers to Sev-1 cases, and freshness refers to the index.
| Commitment | Standard | Premium | Regulated |
|---|---|---|---|
| Serving-plane availability (rolling 28-day window) | 99.9% | 99.95% | 99.95% |
| Acknowledgment | Best effort, business hours | 15 minutes per case, around the clock | 15 minutes per case, around the clock |
| Freshness SLA | None; the P99 90-second objective applies | At most 5 minutes | At most 5 minutes |
| Coverage floor | 0.90 | 0.95 | 0.95 |
| AI traffic behind the interceptor | Fail-open | Fail-open | Fail-open |
The Sev-1 case acknowledgment target measures how quickly Venturi acknowledges a Sev-1 support case you open. It is a per-case target, not an average: each Sev-1 acknowledgment is measured against 15 minutes, and a missed acknowledgment is detected and raised. Under Premium and Regulated it applies around the clock, every day of the year, and is backed by instrumented on-call coverage. The first customer notice and update cadence for an incident Venturi declares are separate clocks: they start when the incident is declared, apply on every tier, and are published in Status & incidents. Response targets for every severity, business hours, and escalation paths are in Support tiers.
The fail-open row covers traffic that reaches the interceptor; it is not an availability commitment for the proxy endpoint (see Proxy endpoint reachability). The RPO and RTO pair in Service objectives is a platform objective on every tier, not a per-tier commitment in this table; any binding recovery commitment is written into your order form.
Measurement basis¶
Every target is measured with a named service-level indicator at a defined point (the interceptor budget end to end at the interceptor seam; freshness at the materialized index; availability over a 28-day rolling window). Scheduled maintenance inside a window that was published on the status surface and notified in advance (see Status & incidents) and failures of customer-side prerequisites are excluded from the availability SLI. The tier commitments use the same basis: the Premium and Regulated index-freshness SLA of at most 5 minutes is measured at P99 at the materialized index over each rolling 28-day window, the attribution-coverage floor is measured over the same rolling 28-day window, and the Sev-1 acknowledgment target applies to each Sev-1 case. Any minimum maintenance notice beyond “notified in advance” is set in your order form. This page defines no service credits or other remedy for a missed commitment; any remedy is set in your order form. Per-tenant objectives hold independently: one tenant’s burst is throttled before a neighbor’s experience degrades.
The error budget¶
The 99.9% objective implies a 0.1% error budget per 28-day window (about 40 minutes); the 99.95% objective for Premium and Regulated tenants leaves about 20 minutes. Fast and slow burn-rate alerts page the on-call before the budget is gone, and an exhausted budget freezes feature rollouts and model promotions until reliability is restored: reliability spend takes precedence over change.
Sign in to send feedback. Opens in a new tab.
Copy page details
Docs feedback: SLAs & SLOs
Page: https://docs.venturi.systems/operations/sla-and-slos/