Support and escalation

DRAFT — support contacts, coverage and response commitments are awaiting agreement. This page describes the information needed to investigate a support request.

Reference · Updated 2026-10-08 · Describes release 0.1.164

DRAFT — support contacts, coverage and response commitments are awaiting agreement. This page describes the information needed to investigate a support request. It does not establish a service-level agreement.

Contacts and commitments

Field Agreed value
Support channel
Primary support contact
Out-of-hours contact
Support hours and time zone
S1 initial response
S2 initial response
S3 initial response
S4 initial response
Update frequency
Escalation contact
Resolution or restoration targets

Support severity

These are proposed support-request levels. They are separate from an alert's severity, an incident's P1–P4 priority and a change's L0–L3 risk tier. Record the observed impact so the receiving support team can confirm the level.

Level Observed impact Example
S1 — critical Platform unavailable for operational work, suspected data loss or an active security compromise Operators cannot access the platform during a live incident
S2 — high A major operational function is unavailable or materially degraded Alerts arrive but investigations cannot start across the affected workspace
S3 — normal A limited issue with an available workaround One connection fails while other investigations continue
S4 — low Guidance, documentation or a non-urgent request Clarification of a report or installation option

For a security concern, use the agreed private support channel. Include the impact and containment already performed; keep credentials and sensitive payloads out of the request.

Report a problem

Use the agreed support channel above. Send:

  1. A short title, proposed support severity and business impact.

  2. The time the issue began, with time zone, affected workspace and whether it affects all users or one role.

  3. Steps to reproduce, expected behavior and observed behavior. State any workaround and recent deployment, connection or configuration change.

  4. The incident ID and investigation ID; add a change or scan ID when relevant. Record IDs are more useful than a screenshot alone.

  5. The live build from GET /healthz, rather than the image tag you intended to deploy. For example:

    curl --fail --silent --show-error https://aiops.example.com/healthz

  6. An audit export covering the affected period, with the export's time bounds recorded. A workspace member with report.view can use Settings · Account → Audit log (/portal/audit) to verify the chain and export it. Platform staff use /ops/audit for platform events. Prefer the JSON export for integrity verification: it is NDJSON with chain fields and a chain-head trailer. A filtered or partial export is not proof of a complete archive.

  7. Relevant error text, the original UTC RCA/report download and, when helpful, a screenshot with secrets and unrelated personal information removed.

The audit export API is GET /api/aiops/<workspace-id>/audit/export; it accepts since, until, fmt=json|csv and a contiguous after_seq cursor. See audit retention and archive verification for exporting a complete archive and verifying it offline. Review attachments before sending them even when the platform has already scrubbed captured data. Never attach passwords, API keys, bearer tokens, private keys or a kubeconfig.

Escalation path

  1. Workspace operator: establish scope, collect the evidence above and record the actions already taken. Use the platform's approval and change records for remediation.
  2. Platform operator: check build, connection/runner health, model errors and the audit trail; distinguish an unavailable provider from a platform failure. Tenant data access still requires membership or an audited, expiring support-access grant.
  3. Engineering support: receive the reproducible report, relevant IDs, build and evidence when the operator cannot restore service or a product defect is suspected.
  4. Service owner / security contact: involve the agreed contact for continuing business impact, suspected compromise or a recovery decision that needs authorization. Use the agreed provider contact when the failing dependency is a cloud or model service.

Escalation timing, named owners, communication frequency and closure acceptance remain to be agreed in the blank table. The support record should retain the confirmed cause, action, verification result and any follow-up work.

Next steps