Files incident

Uploads, create, update and delete operations failures

Notice Resolved View vendor source →

Files experienced a notice incident on May 26, 2026, lasting —. The incident has been resolved; the full update timeline is below.

Started
May 26, 2026, 02:06 PM UTC
Resolved
May 26, 2026, 02:06 PM UTC
Duration
Detected by Pingoru
May 26, 2026, 02:06 PM UTC

Update timeline

  1. resolved May 26, 2026, 02:08 PM UTC

    Between 13:00 and 13:39 UTC, a platform-wide issue occurred, resulting in all uploads, as well as create, update, and delete operations to any resource to fail. Logins and listings were unaffected. The issue has been resolved. We apologize for the inconvenience. A full postmortem will be published here once available.

  2. postmortem Jul 28, 2026, 12:21 PM UTC

    Between 13:30 and 13:39 UTC on May 26, 2026, the [Files.com](http://Files.com) platform experienced a 9-minute issue during which uploads, as well as create, update, and delete operations against any resource, failed. Logins, downloads, and listings were unaffected during this period. Authentication-only and read-only workflows continued to operate normally. The issue was caused by a routine maintenance event on our underlying Aurora MySQL database cluster, which moved the writer role from one database instance to another. Our application failed to recognize this change and continued attempting to write to the previous instance, which was now operating in a read-only capacity. We restored full write capability at 13:39 UTC by restarting the application, which forced it to reconnect to the correct database. [Files.com](http://Files.com) is aware of this role changing mechanism and had built handling for it that had been previously tested in production. That code regressed during a framework upgrade and stopped functioning, and we failed to detect the regression because we did not have a standing test that exercises a database failover in our staging environment. We are correcting both gaps. We are restoring proper failover behavior in the application, and we are adding an automated failover test in staging so that this class of regression cannot ship undetected again. We also identified that the maintenance window for our database cluster is currently scheduled during US business hours, which means routine, automated maintenance events occur at exactly the wrong time of day for our customers. We are moving this window to an off-peak time. We promise a system that works perfectly, all of the time, and today we failed to deliver that to you. We are particularly disappointed because [Files.com](http://Files.com) had previously solved this exact failure mode and allowed a regression to ship. Our entire engineering team is working hard to prevent issues like this one from occurring in the future. If you need additional assistance or continue to experience issues, please contact our Customer Support team.