Box's Admin Console started serving incomplete reporting data from 18:08 UTC on 30 September, and the issue was still open as of Box's last update. The fault sits in Box's own data processing, not in anything you control.
Started
18:08 UTC
Duration
Ongoing
Source
IsDown
Next time
Box is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
What happened?
Box's status page opened this incident at 18:08 UTC, flagging User Engagement Reports and collaboration-related insights in the Admin Console as showing missing or out of date data. Box said it had taken steps to restore data processing and was validating recovery. Updates at 18:53 and 19:51 repeated that recovery was progressing but that the same reports could still show gaps while processing caught up. By the next update, logged at 13:26, Box widened the list of affected reports to include Folders & Files alongside User Engagement, still describing the same missing or outdated data symptom. At 14:44 Box said the issue had been identified and a fix was being implemented, which is the only point in this filing where Box names a cause-adjacent step rather than just describing symptoms. A further update at 21:28 said recovery work remained in progress and that some customers might still see missing or outdated values in their reporting. The most recent update on record, at 10:03, says the same thing: recovery continues, next update when the status changes. No components are listed as affected in Box's own breakdown, and no user reports were filed during this window. Across the whole filing, seven updates span roughly 16 hours of elapsed clock time without a resolved marker, so this incident is still open as far as the record shows.
Learning
This is a data processing and reporting fault inside Box's backend, not a login or file-access failure, which is why an uptime check hitting Box's main service would likely have stayed green the whole time. Reporting pipelines like this sit behind the parts of a service that respond to a simple ping or page load, so they can be broken for hours while every outward-facing endpoint still answers normally. That is also why your own monitoring of your integration with Box would not have caught this: your product calls Box's API and gets a response, it just carries stale or incomplete numbers rather than an error. Box's own history shows 20 incidents in the past 90 days with a median duration of 58 minutes, so a filing that runs this long without a resolved marker stands out against its own pattern. If your product surfaces Box's reporting data to your own users, the practical move is to watch for staleness or gaps in that data directly, since nothing about Box's uptime will tell you it happened. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
