API and database unavailable

Update timeline

1. investigating Jun 29, 2026, 10:51 AM UTC

   We're investigating an outage affecting our API and database. Inbound and outbound calls, the API, and dashboard data may be unavailable or degraded. We'll post updates here as we learn more.

2. investigating Jun 29, 2026, 10:51 AM UTC

   Identified: a fault in our underlying infrastructure has isolated our database — the same root cause as our previous outage. The redundancy/failover that prevents this is in active development but not yet live. We're actively monitoring recovery and will update here as soon as service is restored. We apologize for the disruption.

3. investigating Jun 29, 2026, 11:02 AM UTC

   Resolved: service has been fully restored. The underlying infrastructure fault recovered around 11:00 UTC and our database, API and calls are operating normally again. We verified the database recovered cleanly. Total impact was approximately 10:25–11:00 UTC. We recognize this is the second occurrence of this failure mode, and the redundancy/failover work that prevents it is being prioritized. Thank you for your patience.

4. resolved Jun 29, 2026, 11:06 AM UTC

   Post-mortem — API & database outage, 29 June 2026 Summary. Between approximately 10:25 and 11:00 UTC (~35 minutes), our API, database and call handling were unavailable. A network fault in our underlying hosting infrastructure isolated the host that runs our primary database. Service has been fully restored and the database recovered cleanly, with no data loss. Timeline (UTC). - 10:25 — Monitoring detected the database and API becoming unreachable. - 10:27–10:40 — Confirmed the primary database host was isolated at the network layer: the server itself stayed healthy but was cut off from the network (the hosting provider's own management console could not reach it either). - ~10:57 — The host was recovered by our infrastructure provider. - 11:00 — Database, API and calls fully restored; we verified the database recovered cleanly. Root cause. A network switch fault in our hosting infrastructure isolated the single host that runs our primary database — the machine kept running, but was cut off from the network and the internet. The same class of fault has affected us once before. Because our primary database currently runs on a single host, recovery depended on the provider restoring connectivity rather than on us failing over to a standby. Impact. API requests failed, dashboard data was unavailable, and inbound and outbound calls could not be established (call configuration is resolved from the database). No data was lost. What we're doing about it. The redundancy and failover work that lets us switch to a standby database in a separate location — independent of any single host or network segment — is in active development and being prioritized. Database backups are already replicated off-site. We'll keep posting updates as these safeguards go live. We're sorry for the disruption. If this outage affected your integration and you'd like specifics, reach us at [email protected].

5. resolved Jun 29, 2026, 11:06 AM UTC

   **Post-mortem — API & database outage, 29 June 2026** **Summary.** Between approximately 10:25 and 11:00 UTC (~35 minutes), our API, database and call handling were unavailable. A network fault in our underlying hosting infrastructure isolated the host that runs our primary database. Service has been fully restored and the database recovered cleanly, with no data loss. **Timeline (UTC).** - 10:25 — Monitoring detected the database and API becoming unreachable. - 10:27–10:40 — Confirmed the primary database host was isolated at the network layer: the server itself stayed healthy but was cut off from the network (the hosting provider's own management console could not reach it either). - ~10:57 — The host was recovered by our infrastructure provider. - 11:00 — Database, API and calls fully restored; we verified the database recovered cleanly. **Root cause.** A network switch fault in our hosting infrastructure isolated the single host that runs our primary database — the machine kept running, but was cut off from the network and the internet. The same class of fault has affected us once before. Because our primary database currently runs on a single host, recovery depended on the provider restoring connectivity rather than on us failing over to a standby. **Impact.** API requests failed, dashboard data was unavailable, and inbound and outbound calls could not be established (call configuration is resolved from the database). No data was lost. **What we're doing about it.** The redundancy and failover work that lets us switch to a standby database in a separate location — independent of any single host or network segment — is in active development and being prioritized. Database backups are already replicated off-site. We'll keep posting updates as these safeguards go live. We're sorry for the disruption. If this outage affected your integration and you'd like specifics, reach us at [email protected].