Incident response policy

How incidents reach us

The platform dispatches automated alerts to the configured support alerting webhook (PagerDuty-compatible or Slack), and falls back to structured logs when no external alert sink is configured. Error diagnostics are additionally captured by error monitoring. The conditions that actually alert today are:

• •SLA breaches. Detected by the daily SLA check for conversations that miss their response-time policy.
• •Channel delivery failures. External delivery channels (email, WhatsApp, and similar) that fail to deliver, surfaced by the retry loop that runs every five minutes.
• •High component error rates. Raised from error-rate metrics and failure catch paths against configured thresholds.
• •Commerce action-failure spikes. Guardrail over a rolling 24-hour window: by default 25% or more failed actions across at least 5 attempted actions for a workspace.
• •Low-confidence AI response spikes. Guardrail over a rolling 24-hour window: by default 35% or more low-confidence AI messages across at least 10 AI messages for a workspace.
• •Unresolved risky action items. Proposed, executing, or failed commerce actions left unresolved past the guardrail count (default 10).
• •Webhook dead letters. Outbound webhook deliveries that exhaust their retry attempts.
• •Tenant health risk flags. Aggregated per-workspace health signals; critical flags are dispatched as errors, others as warnings.

Guardrail thresholds are configuration, not constants: they can be tuned per deployment without changing this policy's structure.

Severity ladder

Escalation path

1. 1Detection. An automated alert reaches the support alerting channel, or the incident is reported manually (merchant report, security report, or error monitoring).
2. 2On-duty engineer. Acknowledges the alert, classifies the severity, and acts as incident commander for the duration of the incident.
3. 3Platform admins. Engaged automatically for SEV1, for any security incident, and for any alert that passes its acknowledgement target. Staff actions taken during incidents are recorded in the append-only operator audit.
4. 4Security response. Confirmed security incidents trigger the credential rotation runbook for affected integration credentials, and any break-glass control used (for example the outbound-fetch SSRF validation bypass) is recorded and must be removed within 24 hours of use.
5. 5Founder. Final escalation point; owns communication with affected merchants and any required regulator or partner notification.

Postmortem policy

• •Postmortems are blameless: they examine systems and process, not individuals.
• •SEV1 incidents and any confirmed data-exposure incident receive a written postmortem within five business days of resolution. SEV2 incidents receive one within ten business days.
• •Each postmortem records the timeline, the impact (workspaces and conversations affected), the root cause and contributing factors, and how detection performed — whether the incident was caught by automated alerting or reported from outside. Detection gaps become corrective actions.
• •Corrective actions carry owners and due dates and are tracked to closure. Postmortems are internal documents; a summary is shared with directly affected merchants on request.

Status communication

SEV1 and SEV2 incidents are communicated on the platform status page at /status, at the cadence defined in the severity ladder. Incident entries are closed with a resolution note that references the postmortem when one exists. Merchant-impacting changes that are not incidents (for example, a scheduled migration) are announced in advance through the same page.

Suspected security issues can be reported at any time through the coordinated disclosure process. Please report vulnerabilities privately and allow time for remediation before public disclosure.