Cloudli Communications Status

Postmortem: ## Summary of Events:

On October 8, 2026, at approximately 8:28 AM EDT, Cloudli received a monitoring alarm indicating that some inbound and outbound calls were failing on the Cloudli Connect platform. The issue was intermittent and affected fewer than 5% of total calls. Cloudli began troubleshooting at 8:37 AM EDT and identified the root cause at 9:04 AM EDT. A hotfix was implemented and completed across all Connect nodes at 9:10 AM EDT, at which point call completion fully recovered. Cloudli continued to monitor the platform and confirmed the incident resolved at 9:19 AM EDT.

Incident Analysis and Mitigation Measures:

Initial alarms were received at 8:28 AM EDT, and troubleshooting began at 8:37 AM EDT. At 9:04 AM EDT, the root cause was identified and Cloudli posted an update to its status page. A hotfix was implemented immediately and rolled out to all Connect nodes. Calls began recovering at 9:05 AM EDT, and the rollout was completed at 9:10 AM EDT, at which time the platform entered a monitoring state. Following a short period of proactive monitoring, the incident was formally resolved at 9:19 AM EDT.

Root cause analysis determined that a small percentage of Connect nodes were unable to communicate with the shared storage network. The condition was triggered during the platform’s automated scaling procedures, in which the order of operations used to bring new systems online allowed the telephony service to start before the supporting storage-access module had fully loaded. Nodes brought online in this state could not communicate with the shared storage network, resulting in intermittent call failures. The condition was not related to a scheduled change or maintenance activity and did not affect all Connect nodes.

Service was restored by applying a hotfix to all Connect nodes that ensures the storage-access module is fully loaded before the telephony service starts.

To prevent recurrence, Cloudli has updated its deployment automation scripts so that this startup sequencing is enforced for all newly provisioned systems. This update has been completed and verified, eliminating the edge case that led to this incident.

Final Remarks:

At Cloudli, we take any interruption of service very seriously and are continuously evaluating new processes and mitigation measures that can be proactively implemented to ensure service continuity.

When service interruptions do occur, our incident management procedure prioritizes prompt and clear notification, and timely status and resolution updates to our customers and partners.

We thank you for your continued support. Please feel free to reach out if you would like to discuss the particulars of this incident report further.

Resolved: The issue is fully resolved. We will provide an RFO for this incident within three (3) business days.

Monitoring: The problem has been identified, and we have implemented a solution. We are monitoring the system.

Investigating: We received a monitoring alarm that some inbound and outbound calls are failing. We are investigating the issue.

Postmortem: ## Summary of Events:

On October 8, 2026, at approximately 8:28 AM EDT, Cloudli received a monitoring alarm indicating that some inbound and outbound calls were failing on the Cloudli Connect platform. The issue was intermittent and affected fewer than 5% of total calls. Cloudli began troubleshooting at 8:37 AM EDT and identified the root cause at 9:04 AM EDT. A hotfix was implemented and completed across all Connect nodes at 9:10 AM EDT, at which point call completion fully recovered. Cloudli continued to monitor the platform and confirmed the incident resolved at 9:19 AM EDT.

Incident Analysis and Mitigation Measures:

Initial alarms were received at 8:28 AM EDT, and troubleshooting began at 8:37 AM EDT. At 9:04 AM EDT, the root cause was identified and Cloudli posted an update to its status page. A hotfix was implemented immediately and rolled out to all Connect nodes. Calls began recovering at 9:05 AM EDT, and the rollout was completed at 9:10 AM EDT, at which time the platform entered a monitoring state. Following a short period of proactive monitoring, the incident was formally resolved at 9:19 AM EDT.

Root cause analysis determined that a small percentage of Connect nodes were unable to communicate with the shared storage network. The condition was triggered during the platform’s automated scaling procedures, in which the order of operations used to bring new systems online allowed the telephony service to start before the supporting storage-access module had fully loaded. Nodes brought online in this state could not communicate with the shared storage network, resulting in intermittent call failures. The condition was not related to a scheduled change or maintenance activity and did not affect all Connect nodes.

Service was restored by applying a hotfix to all Connect nodes that ensures the storage-access module is fully loaded before the telephony service starts.

To prevent recurrence, Cloudli has updated its deployment automation scripts so that this startup sequencing is enforced for all newly provisioned systems. This update has been completed and verified, eliminating the edge case that led to this incident.

Final Remarks:

At Cloudli, we take any interruption of service very seriously and are continuously evaluating new processes and mitigation measures that can be proactively implemented to ensure service continuity.

When service interruptions do occur, our incident management procedure prioritizes prompt and clear notification, and timely status and resolution updates to our customers and partners.

We thank you for your continued support. Please feel free to reach out if you would like to discuss the particulars of this incident report further.

Resolved: The issue is fully resolved. We will provide an RFO for this incident within three (3) business days.

Monitoring: The problem has been identified, and we have implemented a solution. We are monitoring the system.

Investigating: We received a monitoring alarm that some inbound and outbound calls are failing. We are investigating the issue.