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. For admitted requests that reach the decision-time interceptor, failures or timeouts in Venturi dependencies behind it leave customer AI traffic fail-open. The drop-in proxy endpoint remains on the request path; see Proxy endpoint reachability.

Where to look

  • The status surface at the app’s /status route shows each component’s current state (serving plane, attribution pipeline, exports, and connectors), active incidents with their updates, scheduled maintenance, and recent uptime. It is tenant-isolated: you see your own deployment’s health, never another customer’s. There is no shared public status page.
  • The degradation API (GET /api/v1/system/degradation) exposes the same signal programmatically as the live set of degradation classes (affected feature, severity, start time, and user impact) for the tenant of the access token you call it with, 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, Microsoft Teams, and signed webhook), honoring your notification preferences and quiet hours. Status subscribers receive the open event, each status transition, and the resolution by email or webhook even while the product UI is unreachable. Scheduled maintenance is published on the status surface in advance, and a maintenance window suppresses the alerts it is expected to trigger and restores them automatically when it closes.

Service-level states

Each component on the status surface reports one of four states, derived from the severity of its degradation class.

State Degradation severity Meaning
operational NOMINAL Data is current and the component is within target.
degraded DEGRADED The component is serving, but freshness or model-backed attribution is outside target; affected results carry degraded markers.
partial-outage PARTIAL One source, pathway, or export path is unavailable; unknowns may increase.
major-outage CRITICAL The component cannot complete requests.

Recovery work, such as replaying events or rebuilding indexes, is reported in the open incident’s updates, and the incident closes only after freshness is verified. 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. Declare the incident, classify its severity using the customer-impact taxonomy below, and name the affected surfaces. The customer notification clocks start at declaration.
  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 A core surface is unavailable or attribution is materially wrong at scale Within 1 hour Every 1 hour
Sev-2 Significant degradation or partial outage with a bounded scope Within 2 hours Every 2 hours
Sev-3 Minor degradation with a workaround and no material impact on correctness Within 4 hours Every 4 hours
Sev-4 Informational or non-urgent issue with negligible customer impact Within 24 hours Every 24 hours

These clocks govern incidents that Venturi declares. Venturi declares an incident from its own monitoring, which pages Venturi’s on-call around the clock, or from a support case it confirms as an incident. Both clocks start when the incident is declared, so a notice is never due before the incident has been acknowledged, and they apply to every affected tenant on every support tier. They are separate from two other clocks:

  • Case acknowledgment targets under your support tier measure how quickly Venturi acknowledges a support case you open. For a Sev-1 case, the target is 15 minutes around the clock under Premium and Regulated (the Sev-1 case acknowledgment target) and best effort during business hours under Standard. If your case leads Venturi to declare an incident, the notice clocks above start at that declaration; if Venturi has already declared an incident for the same impact, its notices reach you on the incident clock whatever your tier.
  • The 24-hour security-breach notification target is the processor notification path triggered by a personal-data breach. It exists so you can meet your own 72-hour GDPR Article 33 deadline and is not the Sev-1 operating cadence. An incident that is both an outage and a personal-data breach runs both paths in parallel.

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.

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: Status & incidents
Page: https://docs.venturi.systems/operations/status-and-incidents/