Wasabi incident
Wasabi Storage Accounts Receiving 'StorageQuotaExceeded' Error Message
Wasabi experienced a minor incident on May 7, 2025 affecting US-Central-1 (Texas) and US-East-1 (N. Virginia) and 1 more component, lasting 10h. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating May 07, 2025, 01:09 PM UTC
We are investigating Storage Quota Exceeded error messages for RCS accounts, our teams are working to resolve this issue.
- identified May 07, 2025, 01:34 PM UTC
We have isolated this issue and are working to ensure all impacted accounts are adjusted appropriately.
- monitoring May 07, 2025, 03:31 PM UTC
A fix has been implemented and we expect that there will be no more new instances of this issue for any Wasabi accounts. If you continue to experience any issues with your Wasabi account, please reach out to our Support Team at [email protected] NOTE: This entry updated to reflect that the incident affected not only RCS accounts but some PayGo accounts as well.
- resolved May 08, 2025, 01:32 AM UTC
The issue affecting some RCS and PayGo accounts with an incorrect 'StorageQuotaExceeded' error message has been resolved. Please reach out to [email protected] if you require further assistance. NOTE: This entry has been updated to reflect that the incident affected not only RCS accounts but some PayGo accounts as well.
- postmortem May 09, 2025, 09:36 PM UTC
From 2025-05-07 03:00 UTC to 2025-05-07 16:00 UTC, a subset of customers experienced data upload issues due to an incorrect storage quota exceeded flag applied to their subaccounts. Specifically, some subaccounts configured with no quota value on their account were incorrectly marked as having exceeded their storage limit. As a result, these subaccounts were temporarily prevented from uploading data. This behavior was the result of a recent update to our billing system, which treated an empty storage quota value as a valid threshold of zero GB and triggered the excessive storage message. By 14:07 UTC, the problematic update was rolled back, and the affected accounts were unflagged. By 16:00 UTC, all impacted subaccounts were verified as having been reset correctly and the service had been returned to normal operational status. ` `