Service support and incidents
Choose the correct support path and provide safe, useful incident evidence.
- For
- All customers
- Owner
- Customer operations
- Outcome
- Report a service problem through the correct path without exposing secrets or unnecessary customer data.
- Last verified
- 2026-08-30
- Next review
- 2026-11-28
- Status
- supported
Use in-app support when an answer depends on a workspace, customer record, provider, or private operating state. Sakhaa does not publish an unverified response-time promise in this guide.
Choose the support path
| Situation | First action | Information to include |
|---|---|---|
| How-to or setup question | Search these public guides | Customer job, role, and provider |
| Workspace or record problem | Create an in-app support ticket | Workspace, page, time, expected and actual result |
| Communication failure | Check Communication reliability first | Channel, provider state, time, safe error code |
| Suspected security issue | Use the security reporting path | Safe summary and contact details only |
Report useful evidence
- Give the page name, approximate time, safe error code, expected result, and actual result.
- State whether the action was repeated and whether it could create a duplicate side effect.
- Include a redacted screenshot only when it adds information.
- Never send passwords, tokens, API secrets, webhook secrets, payment data, or unnecessary customer content.
During an incident
- Stop repeated sends, calls, imports, or automation when completion is uncertain.
- Preserve the visible state and safe request identifiers.
- Use the published support communication for updates and recovery instructions.
- Confirm the final customer and provider state before resuming work.
A separate public status page is not part of the current public contract. Sakhaa will publish its address only after that service is deployed and verified.