Is Files down?

We are investigating reports of delays to Syncs.  Other Files.com services are not affected.

We have identified the cause of the delays to Sync operations, and are currently remediating the issue.  We expect the delayed Syncs to begin to run again shortly. No other Files.com services are affected.

We have resolved an incident which caused delays to Syncs. This incident lasted from 1:20pm UTC to 3:08pm UTC. All Syncs that were delayed have resumed as of 3:08pm UTC.

From 12:20 PM UTC through 2:08 PM UTC on September 23, 2026, [Files.com](http://Files.com) Syncs did not run. Syncs scheduled or triggered during this window were delayed. When service was restored, every delayed Sync resumed on its own and the backlog cleared within minutes. Automations that run as a result of a Sync were delayed along with them. This incident was limited to Syncs and the Automations that depend on them. All other [Files.com](http://Files.com) services operated normally, including file transfers over SFTP, FTP, and the web interface, the API, and Mounts. The incident began when we deployed a routine database change to fix an error we had been tracking. The change needed to rebuild the database table that tracks Sync runs. While that rebuild ran, the database locked the table. Syncs can't run while that table is locked. We failed to recognize that this change affected the Sync table at all. We also failed to recognize that the change would lock that table for the entire rebuild. Changes like this normally finish much faster. This one took far longer than an earlier change to the same table in July, because our database was busier than it had been then. Our team also failed to detect the problem quickly. Because delayed Syncs never started, they never failed, and our alerting is built around failures. About 49 minutes passed before we declared an incident. Once we understood the cause, we had to decide whether to stop the rebuild. Stopping a rebuild of this size partway through carries a real risk of a much longer outage affecting all of [Files.com](http://Files.com). We chose to let it finish, accepting a longer delay to Syncs rather than risk a broader and longer disruption. The rebuild finished at 2:08 PM UTC and Syncs resumed immediately. We are making several changes as a result of this incident. We are adding protections that stop database changes from locking large tables in production, so a change like this one fails safely instead of blocking Syncs. We are adding visibility into the progress of database changes while they run. We are improving our monitoring so that we are alerted as soon as Syncs stop running, not only when they fail. We are also reducing the load on our primary database. The root cause of this incident was a database change that locked the table Syncs depend on for 1 hour and 48 minutes. Contributing causes were our failure to recognize the change's impact before deploying it, higher database load that made the change slow, and monitoring that did not detect stalled Syncs quickly. Many of our customers rely on Syncs to keep critical files moving between their systems and their partners. We know a nearly two-hour delay can hold up real work, and we are sorry. We promise a system that works perfectly, all of the time, and today we failed to deliver that to you. 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.

From 12:20 PM UTC through 2:08 PM UTC on September 23, 2026, [Files.com](http://Files.com) Syncs did not run. Syncs scheduled or triggered during this window were delayed. When service was restored, every delayed Sync resumed on its own and the backlog cleared within minutes This incident was limited to Syncs. All other [Files.com](http://Files.com) services operated normally. The incident was caused by an incorrectly configured database schema update \(DDL\) operation that resulted in unintended locking to a critical database table used to coordinate sync runs. Our database migration process is generally designed to perform schema updates in a zero-downtime manner, and we do database schema updates several times per week without incident as a routine operation. The schema update finished at 2:08 PM UTC and Syncs resumed immediately. We are making several changes as a result of this incident, including improving the logic we use to detect database changes that would cause disruptive locking, so a change like this one fails safely in the future. Many of our customers rely on Syncs to keep critical files moving between their systems and their partners. We know a nearly two-hour delay can hold up real work, and we are sorry. We promise a system that works perfectly, all of the time, and today we failed to deliver that to you. 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.