Files.com Status Page

Jun 5, 2026 · resolved Jun 5

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.

May 26, 2026 · resolved May 26

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.

Apr 1, 2026 · resolved Apr 1

From 17:32 UTC until 19:14 UTC on April 1, 2026, a subset of servers in our primary US region returned TLS errors that produced elevated failure rates across the [Files.com](http://Files.com) Web UI, API, FTP/S, SFTP, and WebDAV. Customers whose traffic was routed to unaffected hosts experienced no issues; others saw login timeouts or "invalid password" messages. **What Happened** While adding an additional domain to our primary wildcard SSL certificate, a bug in our internal certificate management software generated a certificate that omitted the wildcard entries for many of our domains. Our automated certificate rotation process then installed that faulty certificate on a portion of the fleet, causing those hosts to reject connections. Because traffic is load-balanced evenly, some customer sessions failed while others succeeded, making the issue difficult to detect on global dashboards. We identified the certificate issue and generated a corrected certificate within 10 minutes. However, the incorrect certificate remained deployed for an additional 92 minutes. This second delay is the most frustrating part of this incident. Recent modifications to our certificate rotation system had not been reflected in our internal documentation. As a result, our on-call engineers were working from outdated instructions for manually forcing a certificate rotation. It took additional time to uncover the correct process for performing the manual rotation. **What We Have Done To Mitigate This In The Future** We have updated our certificate generation to avoid the accidental omission of wildcard entries through additional validation. We have added an additional monitoring check that which continuously verifies deployed certificates on every public endpoint for the correct wildcard entries. We have documented the certificate-rotation mechanism and emergency override procedure in our internal documentation. We know our customers rely on [Files.com](http://Files.com) for mission-critical workflows, and any service interruption is unacceptable. We apologize for the disruption and appreciate your patience as we improve our safeguards to ensure this does not recur.

Feb 10, 2026 · resolved Feb 10

From approximately 18:20 UTC to 19:23 UTC on 10 February 2026, customers could not preview or edit Office documents in the [Files.com](http://Files.com) Editor.  All other [Files.com](http://Files.com) services remained fully available.   **What happened** Our document-editing service relies on an internal message broker \(Amazon MQ / RabbitMQ\).  A routine broker maintenance reboot caused our editor software to stop accepting new editing sessions but continued to report itself as healthy.  Because our health check logic was flawed and yielding that incorrect status, our load balancer kept sending traffic to the failing servers, resulting in the spinning “Loading…” message you observed.   **What we found** * The editor’s own health endpoint did accurately represent its real status after the broker reboot but that was not known because the failure response was a HTTP 200 OK with the body of “false”. * Our Consul monitoring treated any HTTP 200 as healthy, so no automatic alert fired. * This same chain of events occurred on 20 January but was not fully remediated.   **What we are doing** 1. Updating the Consul health check to validate the response body and fail closed when the editor reports “false”. 2. Enabling CloudWatch logs and metrics for Amazon MQ and alerting on broker restarts and AMQP channel errors. 3. Adding an integration test that continuously opens and saves a document in production and pages engineering if it stalls. 4. We are working to replicate the exact error scenario in staging by creating a full production-like cluster. Once replicated, we will use that data to craft a solution to prevent this error from reoccurring.   We failed to detect the problem promptly and allowed it to recur.  We know you rely on the [Files.com](http://Files.com) Editor for time-critical collaborative work, and we are sorry for the disruption.  The actions above are already in progress, and we will publish further updates on our status page as milestones are reached.  Thank you for your continued trust in [Files.com](http://Files.com).

Jan 20, 2026 · resolved Jan 20

We have resolved an incident causing failures to load the Files.com Editor in our web interface. This incident was resolved at 19:45 UTC on January 20th. Office documents can once again be previewed and edited in the built-in Files.com Editor. We apologize for the inconvenience that this incident caused. We will perform a full postmortem on this incident and publish the report here when it is available.