Builder loading issue

Update timeline

1. resolved Apr 30, 2026, 10:24 AM UTC

   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.

2. postmortem May 07, 2026, 01:56 PM UTC

   ## **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.