Rebuy Outage History

**What happened:** On April 22, 2026, between approximately 11:45 AM and 1:02 PM ET, a subset of shoppers on Rebuy-powered storefronts experienced an inability to load SmartCart V2. Merchants and shoppers who encountered the issue during this window would have seen the cart fail to initialize. All other Rebuy functionality remained operational throughout the incident. ‌ **Duration:** Approximately 1 hour and 17 minutes. ‌ **Impact:** A subset of shoppers on affected storefronts were unable to load SmartCart V2 during the incident window. No data was lost or compromised. ‌ **What caused it:** A software release introduced changes that shifted internal script references in a way that caused the cart to fail for shoppers loading a fresh version of the storefront script during the deployment window. Shoppers with a cached version of the script were unaffected. ‌ **What we did:** Our team identified the issue within minutes of the first report, rolled back to the previous stable release, and confirmed full restoration of SmartCart V2 by 1:02 PM ET — approximately 16 minutes from first report to resolution. ‌ **What we are doing to prevent recurrence:** We have identified the root cause and are implementing structural improvements to our deployment pipeline, including additional validation steps to catch this class of issue before it reaches production.

**What happened** On March 18, 2026, between approximately 12:25 PM and 1:05 PM ET, merchants experienced an inability to access the Rebuy Admin dashboard. Post-purchase flows, Smart Cart, and Rebuy Monetize offers were also unavailable during this window. All on-site storefront functionality remained fully operational throughout the incident. **Duration** Approximately 30-40 minutes. **Impact** Merchants were unable to access the Rebuy Admin interface or manage active offer flows during the incident window. No data was lost or compromised. **What caused it** A routine infrastructure update introduced an unexpected configuration conflict that prevented our admin service from accepting traffic. Once identified, our team rolled back the update to restore full functionality. **What we did** Our team identified the issue, implemented a rollback, and confirmed full resolution within the same hour. We posted updates to our status page throughout the incident. **What we are doing to prevent recurrence** We have identified the root cause and are implementing additional validation steps in our deployment process to catch this class of issue before it reaches production.

**Description:** On March 5th, between 4:58 PM and 5:20 PM EST, merchants may have experienced issues accessing certain areas of the Rebuy Admin. Affected areas included Data Source configuration, Smart Cart V1, and Admin Settings. The disruption lasted approximately 20 minutes. No storefront disruptions occurred for active merchants and no data was lost or corrupted. **Root Cause:** A scheduled security update introduced an incorrect configuration change during our release process, causing the affected Admin areas to become unavailable. **Resolution:** Our engineering team identified the root cause immediately after deployment and deployed a targeted fix, restoring full service by 5:20 PM EST. **Next Steps:** We are adding additional validation steps to our release process to prevent this class of error from reaching production in the future.

**Description:** On February 18th, between 12:44 PM and 1:44 PM EST, merchants may have experienced errors when attempting to create new configurations within the Rebuy platform. Affected actions included the creation of Smart Carts, Checkout Extension Widgets, Merchandising Widgets, Bundle Builder, Smart Flows, and Monetize Widgets. The disruption lasted approximately 60 minutes. Read operations and existing store configurations were not impacted, meaning no storefront disruptions occurred for active merchants, and no data was lost or corrupted. **Root Cause:** A planned platform deployment unintentionally introduced a dependency update that conflicted with how our system handles certain create and update operations, causing those requests to fail. **Resolution:** Our engineering team identified the root cause and deployed a targeted fix within the same deployment window, restoring full service by 1:44 PM EST.