Files incident

Failures loading the Files.com Editor

Notice Resolved View vendor source →
Started
Feb 10, 2026, 08:27 PM UTC
Resolved
Feb 10, 2026, 06:30 PM UTC
Duration
Detected by Pingoru
Feb 10, 2026, 08:27 PM UTC

Update timeline

  1. resolved Feb 10, 2026, 08:27 PM UTC

    We have resolved an incident causing failures to load the Files.com Editor in our web interface. This incident occurred between the times of approximately 18:20 to 19:23 UTC on February 10th. 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.

  2. postmortem Apr 08, 2026, 06:24 PM UTC

    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).

Looking to track Files downtime and outages?

Pingoru polls Files's status page every 5 minutes and alerts you the moment it reports an issue — before your customers do.

  • Real-time alerts when Files reports an incident
  • Email, Slack, Discord, Microsoft Teams, and webhook notifications
  • Track Files alongside 5,000+ providers in one dashboard
  • Component-level filtering
  • Notification groups + maintenance calendar
Start monitoring Files for free

5 free monitors · No credit card required