Is BEE Plugin down?

Today, June 4th, between 11:15 and 14:12 UTC, some customers may have experienced intermittent loading and authorization issues, causing the builders not to load. As a remediation strategy, we decided to roll back the involved component to the latest stable version while we investigate the root cause and determine the best path forward to prevent the issue from happening again. Although we don't expect any further disservice, we keep monitoring our systems.

On June 2, between 5:02 and 5:06 UTC, some users may have experienced issues accessing design previews in the editors and exporting HTML from JSON. The root cause was a brief outage of our multiparser service. The team performed a system reboot and has implemented contingencies to prevent this from recurring while the root cause investigation is ongoing. The service is now stable, and we are continuing to monitor.

Today, between 12:51 UTC and 13:03 UTC, we experienced an outage of our Content Service APIs, impacting all the related services. Our team worked to resolve the issue during this time, including performing a service reboot and retrieving the necessary logs and diagnostics to restore full functionality. All services are now fully operational, and we’re continuing to investigate the root cause to help prevent similar issues in the future. Thank you for your patience and understanding.

We are currently experiencing an issue with the co-editing functionality. As a result, any editor session initialized with co-editing enabled will fail to start. While our team works on a resolution, editor access can be restored by disabling co-editing in the SDK configuration. We'll share further updates as soon as we have more information.

Our team is continuing to investigate the issue with the co-editing functionality. As a temporary measure, editor access can still be restored by disabling co-editing in the SDK configuration.

Following our investigation, we've confirmed that the SDK co-editing functionality was not impacted by the issue reported earlier. Co-editing can remain enabled in your SDK Configuration. We apologize for any confusion this may have caused.

Between 9:14 and 9:46 UTC, an internal update caused the builder to fail loading on new instances. Users who already had the builder open were not affected. We rolled back the change, and service was fully restored. Total duration: 32 minutes. Timeline: Identified (9:14 UTC): An internal update caused the builder to fail loading on new instances. Users who already had the builder open were not affected. Monitoring (9:40 UTC): We rolled back the change and started monitoring recovery. Resolved (9:46 UTC): Service fully restored.

## **Summary** On April 30, 2026, we released an update to the component responsible for loading the Beefree SDK in your applications. Due to an error in this update, approximately 70% of Beefree SDK initializations failed, and the builder did not load. The issue was resolved by reverting to the previous loader version. ## **Timeline \(UTC\)** **09:14** – The loader component update is released for all Beefree SDK customers **09:37** – We detected the issue by trying to access a Beefree SDK instance **09:46** – The loader component has been reverted to the previous version **Incident window**: ~30 minutes ## **Customer impact** During the approximately 30-minute incident, end users attempting to initialize the Beefree SDK builders were not able to load it correctly. Two groups of users were unaffected: * Users who were already working in an active, initialized builder session at the time of the incident. * Applications that re-initialized the builder without fetching the updated loader, relying instead on a previously loaded version. ## **Root Cause** ### **The issue** In preparation for an upcoming feature rollout, we deployed an update to the component that loads the intended version of the Beefree SDK in the host application. The update was intended to address a browser caching issue we had identified in two internal testing environments. However, the update caused the loader to provide an incorrect path to the SDK version to be executed, resulting in the builder failing to load. ### **Why did we not catch this problem in our testing?** Our initial testing covered only internal instances, and the programming error that caused the issue was not caught during our review process, which was asynchronous in this case. Additionally, our existing automated tests did not cover this initialization scenario. ## **Action Items** ### **Immediate action taken:** * Reverted the loader to the previous stable version. ### **Next steps and short-term action items:** * We have since corrected the programming error and re-deployed the loader update on May 4, 2026, with no issues. * We will enhance our automated testing to ensure that builder initialization is explicitly verified at the end of every deployment process for infrastructure components that could affect it. * We will extend our AI-assisted pull request review to cover all components that may affect builder initialization, not just the frontend. Both action items are high priority and will be completed within the next two weeks.