Previous incidents

We can see there were several disruptions to Azure Load Balancing service in ZA North at 10:43, 10:52, 10:58, and at 11:01 (all South African local time). This is most likely due to Azure cycling some workloads.

When Azure reset these connections, these result in load spikes which can slow the system down with thousands of users reconnecting at the exact same time. We will raise an issue with Azure to understand why the connections were reset, and we apologise for the inconvenience.

We are seeing service restored - and carrier has confirmed restored

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.