Skip to content

Status & incidents

Venturi reports service health through the product itself, the API, and your configured notification channels. Incidents are classified by customer impact, affected surface, freshness, and recovery path. Whatever the state, customer AI traffic remains fail-open: no degradation below can block your requests.

Where to look

  • The status surface shows each component’s current state, active incidents, scheduled maintenance, and uptime history. It is tenant-isolated: you see your own deployment’s health, not a shared global page.
  • The degradation API (GET /api/v1/system/degradation) exposes the same signal programmatically, and every attribution record carries its own per-result degradation_state (see Observability & diagnostics).
  • Notifications for incidents and maintenance are delivered in-product and over your configured channels (email, Slack, webhook), honoring your notification preferences and quiet hours. Maintenance windows suppress the alerts they would expectedly trigger and restore them automatically.

Service-level states

State Meaning
Healthy Data is current and services are within target.
Delayed Attribution is still correct but freshness is outside target.
Partial One source or pathway is degraded; unknowns may increase.
Unavailable A serving-plane surface is down or cannot complete requests.
Recovering The service is replaying events or rebuilding indexes.

Service-level state summarizes the deployment; the per-result degradation_state on each attribution record tells you how a specific number was produced. The two never disagree silently: a result produced under degradation says so in its evidence.

Incident lifecycle

  1. Detect the impact through monitoring, customer report, or health checks.
  2. Classify severity using the customer-impact taxonomy below and name the affected surfaces.
  3. Communicate status and the expected next update within the severity-bound clock.
  4. Mitigate or fail to a conservative operating mode.
  5. Recover, verify freshness, and close the incident.
  6. Publish a post-incident summary: a plain-language, customer-facing root cause analysis within ten business days for a Sev-1 (and on request for a Sev-2).

Security incidents follow the stricter notification path in Compliance: notification without undue delay, targeting 24 hours from awareness, in support of your own 72-hour GDPR Article 33 duty.

Customer notification commitments

Severity Customer-impact anchor First customer notice Update cadence until resolution
Sev-1 Critical outage or severe degradation affecting multiple tenants or a core plane Within 1 hour Every 1 hour
Sev-2 Material degradation or partial outage affecting a bounded tenant or component scope Within 2 hours Every 2 hours
Sev-3 Minor degradation with a workaround and limited customer impact Within 4 hours Every 4 hours
Sev-4 Informational or non-urgent issue with negligible customer impact Within 24 hours Every 24 hours

These are incident-communication clocks. The 15-minute Sev-1 MTTA is a milestone-scoped support acknowledgement target: it measures how quickly an incident is acknowledged internally or in the support case, not when the first customer status notice is due. The 24-hour security-breach notification target is a separate processor-notification path triggered by a personal-data breach; it is not the Sev-1 operating cadence.

What customers can see

The product shows degradation state, connector freshness, index freshness, and whether results are estimated, reconciled, stale, or unavailable. Nothing degrades silently: staleness beyond the freshness objective is labeled with an as-of timestamp before it can mislead anyone.