Buzzeasy Outage History

Started Sep 30, 2026, 05:50 AM UTC· resolved Sep 30, 2026, 08:45 AM UTC

1. investigating Sep 30, 2026, 05:50 AM UTC

   We are currently investigating an incident that manifests as userts being unable to log in to our web interface..

2. identified Sep 30, 2026, 06:45 AM UTC

   We've identified the source of the problem and are working to fix it as soon as we can..

3. monitoring Sep 30, 2026, 07:05 AM UTC

   We implemented a fix and are currently monitoring the result..

4. resolved Sep 30, 2026, 08:45 AM UTC

   This incident has been resolved. We'll post the root cause shortly as the "postmortem" of this incident..

Read the full incident report →

Started Aug 25, 2026, 07:30 AM UTC· resolved Aug 25, 2026, 09:55 PM UTC

1. investigating Aug 25, 2026, 07:30 AM UTC

   We are currently investigating reports of slowness affecting the Agent UI. The issue is being investigated with high priority..

2. investigating Aug 25, 2026, 07:37 AM UTC

   We will provide another update as soon as more information is available..

3. investigating Aug 25, 2026, 09:20 AM UTC

   We have identified a component that could be contributing to the reported Agent UI slowness and are currently performing additional checks around this area. We are continuing our investigation..

4. investigating Aug 25, 2026, 11:02 AM UTC

   We have opened a high-priority support case with Microsoft regarding the reported Agent UI slowness affecting services hosted on Azure. We are continuing to investigate the issue with Microsoft..

5. investigating Aug 25, 2026, 01:51 PM UTC

   Microsoft has reviewed the issue and is continuing its investigation into the observed delays with Azure services. They have requested some additional technical and diagnostic information from our side to help identify the underlying cause. We are gathering the required details and will provide them to Microsoft. We’ll keep you updated as soon as we receive further findings or guidance..

6. resolved Aug 25, 2026, 09:55 PM UTC

   The Graia SRE team has completed the infrastructure mitigation and migrated the affected services to a secondary Azure Service Bus namespace. Following the migration, no further Agent UI delays have been observed and the platform has remained stable during testing and monitoring. We will continue to monitor service latency and overall platform health overnight while Microsoft continues its investigation into the underlying Azure issue. This incident is now resolved. Thank you for your patience..

Read the full incident report →

Started Aug 04, 2026, 07:40 AM UTC· resolved Aug 04, 2026, 09:39 AM UTC

1. investigating Aug 04, 2026, 07:40 AM UTC

   We are currently investigating this incident..

2. monitoring Aug 04, 2026, 07:42 AM UTC

   Recording Manager service restored and operational. Internal voice test successful. Stuck-call recovery initiated..

3. monitoring Aug 04, 2026, 07:47 AM UTC

   Customers confirmed service was operational..

4. investigating Aug 04, 2026, 08:07 AM UTC

   Slowness identified in the Recording Manager service..

5. identified Aug 04, 2026, 08:13 AM UTC

   Second automatic restart of the Recording Manager service initiated..

6. monitoring Aug 04, 2026, 08:20 AM UTC

   Recording Manager service restored and operational. Internal voice test successful. Stuck-call recovery initiated..

7. monitoring Aug 04, 2026, 08:26 AM UTC

   Customers confirmed service was operational..

8. investigating Aug 04, 2026, 09:22 AM UTC

   Third automatic restart of the Recording Manager service initiated..

9. monitoring Aug 04, 2026, 09:25 AM UTC

   Recording Manager service restored and operational. Internal voice test successful. Stuck-call recovery initiated..

10. resolved Aug 04, 2026, 09:39 AM UTC

    Customers confirmed service was operational. This incident has been resolved..

Read the full incident report →

Started Jul 20, 2026, 08:42 AM UTC· resolved Jul 20, 2026, 09:23 AM UTC

1. investigating Jul 20, 2026, 08:42 AM UTC

   The problem manifests to users of the portal web administration interface by it failing to load beyond the initial blank screen or to load page-specific content when navigating between menus. Contact center agents also see an error message such as “Failed to get voice configuration”, are unable to receive or initiate calls or are faling to load the web application entirely..

2. identified Jul 20, 2026, 08:52 AM UTC

   The SRE team discovered the fact that a node is unresponsive by noticing the unusual metrics it is exhibiting..

3. identified Jul 20, 2026, 09:05 AM UTC

   The node pool was expanded with an additional node to take over the workload of the unresponsive one..

4. identified Jul 20, 2026, 09:08 AM UTC

   The existing pods that were on the unreachable node were moved away from it..

5. monitoring Jul 20, 2026, 09:15 AM UTC

   Graia team members observed recovered functionality..

6. resolved Jul 20, 2026, 09:23 AM UTC

   This incident has been resolved..

Read the full incident report →

Started Jun 08, 2026, 01:57 PM UTC· resolved Jun 08, 2026, 02:09 PM UTC

1. investigating Jun 08, 2026, 01:57 PM UTC

   Automated monitoring detected the issue and generated an alert..

2. identified Jun 08, 2026, 02:03 PM UTC

   Test calls confirmed an issue affecting voice call processing on the impacted server..

3. monitoring Jun 08, 2026, 02:05 PM UTC

   Recovery actions were initiated to restore service..

4. resolved Jun 08, 2026, 02:09 PM UTC

   Follow-up testing confirmed that voice services had returned to normal operation..

5. monitoring Jun 09, 2026, 02:00 PM UTC

   The incident was caused by a software defect within a third-party voice gateway component that was triggered under specific high-load conditions. When the defect was triggered, the affected voice server was no longer able to process call-related activities correctly, resulting in disruption to voice client connectivity, call control functions, and audio handling for impacted calls Service was restored following recovery actions on the affected voice server Corrective Action Plan: Improvements to the Call Probing Implementation Deploy new Voice Gateway version 20.20.0 GA on QA Enable Active-Active Voice Gateway functionality on QA Deploy new Voice Gateway version 20.20.0 GA on Production Enable Active-Active Voice Gateway functionality on Production for Instance 5-6.

Read the full incident report →

Started May 22, 2026, 02:35 PM UTC· resolved May 22, 2026, 02:48 PM UTC

1. investigating May 22, 2026, 02:35 PM UTC

   Agents began observing symptoms of unresponsive or silent calls..

2. identified May 22, 2026, 02:46 PM UTC

   A telephony service on one of the EU customer virtual machines experienced a software crash. Automatic recovery restarted the affected service..

3. monitoring May 22, 2026, 02:47 PM UTC

   The first successful call from the recovered service was observed..

4. resolved May 22, 2026, 02:48 PM UTC

   This incident has been resolved..

5. monitoring May 28, 2026, 02:00 PM UTC

   The incident was caused by a third-party voice gateway component becoming overloaded under specific high-load conditions. This overload triggered a software defect in the component, leading to worker thread conflicts. As a result, voice client connectivity for affected calls was disrupted, causing loss of call control and audio handling failures. Corrective Action Plan: Call Probing Implementation Automated Stuck Call Handling.

Read the full incident report →

Started May 09, 2026, 12:23 PM UTC· resolved May 09, 2026, 02:00 PM UTC

1. investigating May 09, 2026, 12:23 PM UTC

   We are currently investigating the reported incident that some customers are unable to handle inbound voice calls. This is affecting all agents of the affected customers but only customers hosted on one of our voice server instances..

2. identified May 09, 2026, 01:00 PM UTC

   Tenants hosted on the affected voice instance were moved to the secondary instance while the investigation continues..

3. monitoring May 09, 2026, 01:33 PM UTC

   We recovered the affected voice instance and performed test calls. The condition causing the service disruption was identified, and successful test calls after moving a test tenant back to the original instance confirmed that the instance was operating normally again..

4. resolved May 09, 2026, 02:00 PM UTC

   This incident has been resolved. As a precaution, tenants continue to run on the secondary voice instance until the root cause analysis can be completed..

5. monitoring May 12, 2026, 09:36 AM UTC

   The incident was caused by a low-level third-party voice gateway component becoming overloaded, resulting in loss of voice client connectivity for agents. Initial analysis indicates a potential software bug in the affected component related to worker thread collisions under a specific combination of call load conditions. Although warning logs were generated by the affected service, the monitoring system did not detect the condition in time due to vendor-introduced log syntax changes that no longer matched the existing monitoring pattern. Corrective action plan: * Finalize voice gateway component bug assessment and apply fixes. * Update and validate monitoring rules for the new log entry syntax..

Read the full incident report →

Started Apr 22, 2026, 05:37 AM UTC· resolved Apr 22, 2026, 07:15 AM UTC

1. investigating Apr 22, 2026, 05:37 AM UTC

   Some customers are seeing that they cannot receive/make calls or that agents cannot end ongoing ones. We’re aware of the issue and are working on it urgently. We’re really sorry to be holding you up today! Please know our teams are working hard to get everything up and running, and we will update you as soon as possible with the latest information..

2. identified Apr 22, 2026, 06:01 AM UTC

   We identified the problem and have started working on recovering functionality..

3. monitoring Apr 22, 2026, 06:10 AM UTC

   We recovered functionality of the affected service and are continuing to monitor the system..

4. resolved Apr 22, 2026, 07:15 AM UTC

   The incident will now be considered closed with the root cause to be announced when we conclude the investigation. In our status page's terms, this will come as a 'Postmortem' update to the incident..

5. monitoring May 04, 2026, 08:51 AM UTC

   The issue was caused by a backlog in the voice processing layer, which led to internal call queues becoming saturated. As a result, new calls could not be established, and existing sessions could not be properly terminated. Further investigation showed that this condition was triggered by a recently deployed minor version update to a third-party telephony component within the voice server (applied during the maintenance window on April 18, 2026). This version exhibited stability issues when handling higher call volumes, leading to the observed behaviour. Corrective action plan: Rollback to the previous stable version of the voice server software. .

Read the full incident report →

Started Apr 18, 2026, 03:00 AM UTC· resolved Apr 18, 2026, 03:00 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Apr 06, 2026, 11:15 AM UTC· resolved Apr 06, 2026, 02:45 PM UTC

1. investigating Apr 06, 2026, 11:15 AM UTC

   The System Reliability Engineering (SRE) team was alerted by the Geomant Helpdesk following a report from a partner that inbound calls were not reaching agents..

2. investigating Apr 06, 2026, 11:52 AM UTC

   After initial checks, SRE rebooted the first affected voice instance and performed test calls. The system did not recover. During the reboot, all Graia tenants were automatically failed over to the secondary instance..

3. investigating Apr 06, 2026, 12:07 PM UTC

   A broader system investigation observed an unusually high volume of outbound calls initiated by a campaign-based tenant, which was noted as a potential contributing factor and investigated further..

4. investigating Apr 06, 2026, 12:40 PM UTC

   Senior members of the development team were engaged for further investigation..

5. identified Apr 06, 2026, 01:30 PM UTC

   A blockage in the call processing flow was identified, and remediation steps were initiated.

6. monitoring Apr 06, 2026, 01:43 PM UTC

   The blockage was cleared, and calls began to be successfully processed. Monitoring continued..

7. monitoring Apr 06, 2026, 01:57 PM UTC

   The blockage reoccurred, again impacting call handling..

8. monitoring Apr 06, 2026, 02:20 PM UTC

   The underlying process responsible for the blockage was identified and stopped..

9. resolved Apr 06, 2026, 02:45 PM UTC

   This incident has been resolved..

10. monitoring May 04, 2026, 09:37 AM UTC

    The incident was caused by the number of concurrent active calls across tenants exceeding the capacity of a micro-service responsible for temporary call state storage. This situation was triggered by an unexpectedly high-volume campaign workload from a tenant, contributing to a significant increase in overall system load. While the underlying voice infrastructure had sufficient capacity to handle the traffic, the supporting micro-service reached its storage limit. This resulted in a processing blockage that prevented calls from being fully established. Corrective action plan: Migrate voice instance state storage from in-memory grain storage to blob-based storage.

Read the full incident report →

Started Apr 01, 2026, 11:05 AM UTC· resolved Apr 01, 2026, 12:55 PM UTC

1. identified Apr 01, 2026, 11:05 AM UTC

   One of our voice servers suffered from having a full virtual drive which prevented it from accepting calls. During the time while the incident was ongoing, this voice server replied with an error response to any inbound SIP INVITE requests. .

2. monitoring Apr 01, 2026, 11:15 AM UTC

   We moved all Graia CCaaS tenants to an alternative voice server of the affected server group..

3. resolved Apr 01, 2026, 12:55 PM UTC

   This incident has been resolved..

4. monitoring Apr 02, 2026, 02:19 PM UTC

   The incident was caused by a transient issue following a recent upscale of the affected voice instance to a higher tier (performed the previous night). Post-upgrade validation (test calls and log checks) did not reveal any issues, and all other instances operated normally. Corrective action plan: 1\. Extend criteria of automatic fail-over in case of secondary disk mount failures 2\. Enhance post-scaling validation 3\. Verify SIP routing logic on Customer/Partner side to handle 5xx and 6xx SIP responses.

Read the full incident report →

Started Mar 10, 2026, 01:10 PM UTC· resolved Mar 10, 2026, 01:10 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Feb 05, 2026, 10:30 AM UTC· resolved Feb 05, 2026, 11:47 AM UTC

1. investigating Feb 05, 2026, 10:30 AM UTC

   Dear customer, We have noticed degraded performance on our Agent UI where customers report delayed reactions from the interface. We are currently investigating this issue and will come back soon with an update on the matter. Thank you, Graia team.

2. investigating Feb 05, 2026, 11:13 AM UTC

   The incident seems to have manifested mainly in the context of inbound calls which is now subsiding after a quick intervention. We are continuing to monitor and test the system..

3. investigating Feb 05, 2026, 11:15 AM UTC

   Relevant DevOps work items: Incident 145656: AUI frozen, stuck in a loop.

4. resolved Feb 05, 2026, 11:47 AM UTC

   We are closing this incident as the reported problems have been resolved. This has confirmed by not only our own tests and monitoring but also from several of our customers who had originally reported the fault. We will continue by investigating the root cause to prevent this issue in future. Thank you for your understanding, Graia Team.

Read the full incident report →

Started Jan 16, 2026, 01:00 PM UTC· resolved Jan 16, 2026, 01:00 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Jan 09, 2026, 02:19 PM UTC· resolved Jan 09, 2026, 02:19 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Nov 24, 2025, 07:15 AM UTC· resolved Nov 24, 2025, 07:15 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Oct 29, 2025, 03:49 PM UTC· resolved Oct 29, 2025, 03:49 PM UTC

No vendor updates were posted for this incident.

Read the full incident report →

Started Oct 09, 2025, 09:29 AM UTC· resolved Oct 09, 2025, 09:29 AM UTC

No vendor updates were posted for this incident.

Read the full incident report →