Is Files.com Down?

Between 17:13 UTC on June 4, 2026 and 15:12 UTC on June 5, 2026, [Files.com](http://Files.com) customers using SFTP with ed25519 SSH key-based authentication experienced authentication failures. This incident was limited to SFTP connections using ed25519 public keys. All other authentication methods — including password-based SFTP authentication, RSA key authentication, and all other [Files.com](http://Files.com) protocols and services — continued to operate normally throughout this period. We deployed a change to our SFTP server infrastructure intended to improve host key handling, but it inadvertently broke the authentication path for clients using ed25519 public keys. We failed to catch this regression before it reached production. We use automated testing to avoid this sort of regression, but there was a gap around specific combinations of ciphers and authentication flows. We have expanded our test suite to ensure every possible SFTP authentication path is tested. In addition, we did not manually verify ed25519 authentication during pre-deploy validation. This was a failure in our testing process and we are updating our guidelines around similar changes going forward. We also failed to detect this regression through our own monitoring. A latent bug in our internal compliance logging pipeline caused log events from the affected authentication sessions to be silently dropped rather than stored. Because these failed login attempts were not surfacing in our monitoring systems, we did not detect the incident internally—we learned of it from customer reports beginning on the morning of June 5, 2026. We have resolved the logging bug, and added alerting to this part of the logging pipeline to ensure future failures are surfaced immediately. We resolved the incident at 15:12 UTC on June 5, 2026 by rolling back the SFTP change and restarting all SFTP services across all regions. We confirmed the fix across affected customer accounts in all regions. As soon as we completely understood the situation, we posted an update to our status page. The root cause of this incident was [Files.com](http://Files.com)'s insufficient test coverage for all possible authentication paths, combined with a monitoring failure that prevented early detection. We have corrected both. Our customers trust us with their most sensitive and time-critical workflows, and we understand the disruption this caused. We are sorry. Our entire engineering team is committed to the improvements needed to prevent this type of incident from occurring again. If you need additional assistance or continue to experience issues, please contact our Customer Support team. --- [2026-06-05T10:51:02.987-07:00] (resolved) We resolved an incident on the Files.com platform that caused SFTP logins using ed25519 SSH keys for authentication to fail. This incident impacted a small portion of users on our platform. Only SFTP, and only key-based logins using ed25519 keys were impacted by this incident. No other services or authentication types were effected. This incident occurred between from 17:13 UTC on 6/4/26 and 15:12 UTC 6/5/26, and was fully resolved by a code deploy. We will provide a detailed postmortem and RCA for this incident.

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. --- [2026-05-26T07:12:33.648-07:00] (resolved) 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.