Box Status Page

May 22, 2026 · resolved May 22

After further monitoring, this incident is now considered resolved. Box services have been restored to full functionality. Please contact Box Support at https://support.box.com/ if you continue to experience any issues.

May 14, 2026 · resolved May 14

We recently addressed issues affecting **Enterprise Events API**. We would like to take the opportunity to further explain these issues and the steps we have taken to keep them from happening in the future. ‌ Between 2:31am and 4:45pm PDT on May 14, 2026, some users may have experienced difficulties while working in Box. During this time, customers using the streaming Enterprise Events API experienced delivery delays of up to 6.5 hours. The issue occurred when an internal indexing service unexpectedly generated events at an unconstrained rate, which caused a significant concentrated spike in the total events volume. We were able to resolve the issue by redirecting those events from our streaming enterprise events pipeline for later processing. In addition, we will exclude events originating from internal services from our enterprise events processing pipelines and proactively deprioritize unexpected surges in events to prevent similar issues from occurring in the future. ‌ **Analysis** ‌ There were a number of contributing factors leading to this incident: ‌ Our internal search indexing service produced events, which should not have been created, at a rate significantly exceeding enterprise usage. These events were published to a queue to be written to the persistent datastore. Also, these events were concentrated in certain access patterns causing hot spotting in some database partitions. The significantly reduced throughput of these partitions caused the subscriber to fall behind. Once these access patterns were identified and the corresponding events removed, service was resolved promptly. Moving forward, these events will not be published. ‌ **Corrective Actions** ‌ The following corrective actions have been completed or are planned: ‌ * **Disable Event Publishing for Search Services** - We are disabling enterprise events from being produced and processed from Box internal services. * **Deprioritize Surge Workloads** - We will monitor for workloads generating significant volumes of event data and deprioritize those events from the primary pipeline. * **Update Incident Response Procedures** - We are updating our runbooks to account for these conditions and related actions. ‌ We are continuously working to improve Box and want to make sure we are delivering the best product and user experience we can. We hope we have provided some clarity here and we would be happy to answer any questions you may still have regarding this matter.  Sincerely, The Box Team

May 7, 2026 · resolved May 7

We recently addressed issues affecting folder and collection browsing, and related APIs. We would like to take the opportunity to further explain these issues and the steps we have taken to keep them from happening in the future. Between 05:22 PM PDT and 07:04 PM PDT on May 6, 2026, some users may have experienced difficulties while working in Box. During this time, users reported failures and elevated errors when loading folders and collections, intermittent service errors, and degraded AI-related functionality. The issue was caused by runtime saturation in a backend API service that had been gradually approaching its capacity limits over several weeks. During peak traffic hours, multiple service instances simultaneously became unable to respond to internal health checks within the configured timeout. As those instances were restarted, traffic shifted to the remaining instances, increasing load on them and creating a cascading failure. We mitigated the issue by stopping the restart cycle, routing traffic to alternate paths, and increasing service capacity. ‌ **Analysis** This incident revealed several contributing causes: * Insufficient scaling signals — autoscaling was primarily configured around CPU utilization. For this service, CPU utilization did not accurately reflect runtime saturation, so the fleet did not scale early enough in response to the actual bottleneck. * Health check sensitivity under load — health checks were configured with timeouts that did not account for the service’s behavior under sustained runtime saturation. Once instances became slow to respond, restarts amplified the problem by shifting more traffic to the remaining instances. * Gradual capacity erosion without alerting — the service had shown intermittent health check failures during prior peak traffic periods. Those earlier events were narrow enough to self-recover, but they were not surfaced as a clear trend requiring action. * Retry amplification — as service instances became unavailable, upstream retry behavior added additional load to the remaining healthy instances, accelerating the cascade. This incident highlighted opportunities for improvement in how we detect and respond to runtime saturation that is not always visible from CPU metrics alone. It also reinforced the need for stronger end-to-end observability, clearer health-check visibility, and validated mitigation paths for service instability. ‌ **Corrective Actions** Box has initiated the following corrective actions: * Improved runtime monitoring and alerting — we added alerts for runtime saturation metrics that detect this class of failure independently of CPU utilization, providing earlier warning before customer impact occurs. * Revised autoscaling strategy — we reconfigured autoscaling to trigger on signals that reflect actual service capacity and validate that the fleet scales correctly under realistic load conditions. * Health check and resilience tuning — we are reviewing health check configurations and retry behavior to reduce the risk that transient runtime saturation can turn into cascading restarts. * Capacity validation and load testing — we are establishing load testing against production-representative traffic patterns and maintaining capacity headroom until the service's efficiency improvements are validated. * Runtime performance improvements — we identified and are implementing changes to the service framework that significantly reduce per-request overhead, providing more headroom against future saturation. ‌ We are continuously working to improve Box and want to make sure we are delivering the best product and user experience we can. We hope we have provided some clarity here and we would be happy to answer any questions you may still have regarding this matter. Sincerely, The Box Team

Apr 27, 2026 · resolved Apr 27

After further monitoring, this incident is now considered resolved. Search with metadata has been restored to full functionality. If you continue to experience any issues, please contact Box Support at https://support.box.com.

Apr 3, 2026 · resolved Apr 3

On April 2, 2026 between 8:19 PM PDT and 11:56 PM PDT, some users may have experienced difficulties while working in Box. During this time, Box Sign users might have experienced errors while creating new signature requests, accessing existing signature requests, or attempting ~~been unable~~ to access the service. The issue occurred as a result of an erroneous change made by a third-party infrastructure provider. We were able to resolve the issue by escalating it to the provider. In addition, we are working to improve the reliability of the Box Sign service by enhancing our disaster recovery processes to prevent similar issues from occurring in the future.  ‌ We are conducting a full engineering postmortem and our overview is subject to change with further analysis and findings. In the event our continuing investigation yields further substantive findings, we may publish additional analysis after the conclusion of the full engineering postmortem. We are continuously working to improve Box and want to make sure we are delivering the best product and user experience we can. We hope we have provided some clarity here and we would be happy to answer any questions you may still have regarding this matter.  Sincerely, The Box Team