Is Files down?

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 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 failed to catch this regression before it reached production. A deployment to our SFTP server infrastructure introduced a change intended to improve host key handling, but it inadvertently broke the authentication path for clients using ed25519 public keys. Our automated test suite covered RSA key authentication but did not include tests for ed25519 keys, and we failed to manually verify ed25519 authentication during pre-deploy validation. This was a gap in our testing discipline that we are correcting.   We also failed to detect this failure through our own monitoring. An existing issue 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 are adding alerting on this pipeline to ensure failures are surfaced immediately.   We resolved the incident at 15:12 UTC on June 5, 2026 by rolling back the FPS deployment and restarting all SFTP servers across all regions. We confirmed the fix across affected customer accounts in all regions.   We are also addressing a process gap: our status page update was posted more than 20 hours after incident onset, which is unacceptable. We are reconciling internal process documentation to ensure status updates are posted promptly in future incidents.   The root cause of this incident was [Files.com](http://Files.com)'s insufficient test coverage for a change that was deployed to production, combined with a monitoring gap that prevented early detection. We are correcting 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.

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.

We have resolved an SSL certificate configuration issue affecting a subset of servers in our USA region. This incident occurred between the times of 17:33 UTC and 19:14 UTC and resulted in elevated error rates during this time window. Most traffic did operate successfully during this time window. We are still in the process of determining the exact scope of impact.

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.