Previous incidents

Historically we have allowed verified Caller IDs to be used on our native telephony platform even if the Caller ID does not belong to us. This is always supported on a best endeavours basis, as some receiving carriers will reject calls if they come from a Caller ID not owned by the sending carrier.

An upstream change made by a Carrier overnight has now blocked this behaviour in the majority of cases. As this service was only provided for emergency failover rather than primary use, it shouldn...

Final update from Cloudflare

All Cloudflare services have been restored and are now fully operational. We are moving the incident to Monitoring while we watch platform metrics to confirm sustained stability.

This issue was caused by a load spike on a primary datastore disk which began at 09:41 and was causing requests to complete slower than normal.

At 09:47 the cause was identified and blocked from causing further load. This immediately improved the speed of responses to our API.

At 09:49 additional capacity was brought online as a precaution, although normal levels of service had already been restored.

We apologise for the brief slowdown.

This incident has been resolved. The underlying host experienced hardware failure within Azure, and the server was re-provisioned on an alternative host.

Update from Azure:

What happened?

Between 23:30 UTC on 13 May 2025 and 08:20 UTC on 14 May 2025, you were identified as an Azure customer in the South Africa North and South Africa West regions who may have experienced intermittent connectivity loss and increased network latency.

What went wrong, and why?

A third-party telecom network disruption in the affected regions was identified as a contributing factor to this event.

How did we respond?

23:30 UTC on 13 May 2025 - Customer impact...