Billing support
Service Status and Incidents
Define status-page components, incident severity, update timelines, and postmortem content.
A public status page should help developers distinguish application failures from APIQIK gateway, model, or underlying inference-node problems and provide ongoing updates.
Status-page URL pending confirmation. Before release, provide a subscribable status page, historical availability, and support escalation entry points.
Recommended monitored components
- Gateway and authentication, console, billing, and model catalog.
- Chat, streaming, tool calling, and released embeddings, reranking, and multimodal endpoints.
- Availability and performance degradation by model or provider region.
Incident lifecycle
- Investigating: Confirm symptoms, start time, affected components, and temporary guidance.
- Identified: Explain the diagnosed failure scope and current mitigations.
- Monitoring: Deploy the fix and continue observing error rates, latency, and backlog.
- Resolved: Provide recovery time, final impact, and postmortem plans.
Postmortems
Major incidents should include a timeline, user impact, root cause, why failover succeeded or failed, data and billing impact, corrective actions, and owners. A statement that service is restored is not enough.