From 21:45 UTC to 22:55 UTC on 9 January 2026, a subset of customers with custom domains enabled experienced elevated “500 – Internal Server Error” responses when uploading (and in some cases downloading) files through certain Remote Server Mount–backed transfer paths, including Files.com Agent- backed connections.
A code change in the Files.com API control plane, intended to correct a bug in custom-domain uploads, introduced an unintended error condition affecting uploads routed through remote server mounts for sites with custom domains. Specifically, the API returned an invalid (blank) upload URL in its response, which caused subsequent upload steps to fail and resulted in HTTP 500 errors.
These errors were immediately generated and logged by our application. Under normal conditions, this error volume would have triggered an automated PagerDuty alert to our on-call engineering team. However, a misconfiguration in our error-tracking system (Sentry) caused the majority of these error events to be suppressed. As a result, the expected alerts were not generated, and the issue was not immediately paged to on-call staff.
Although our CI and production canary testing do exercise Agent-backed and Remote Server Mount upload workflows, those tests are not currently executed against customer sites using custom domains. Because this defect only manifested when custom domains were combined with remote server mounts, this edge case was not detected during pre-production testing.
The issue was ultimately identified through customer reports, which prompted immediate investigation and remediation. A patch was verified in staging at 22:48 UTC and deployed to production at 22:55 UTC, fully restoring normal operation. We corrected the Sentry configuration and deployed new, version-controlled Terraform configuration to ensure that critical production errors always generate complete telemetry and alerts.
We will also expand automated tests and deployment canaries to explicitly cover custom domain configurations so that this class of issue is detected during pre- production testing.
This incident represents our most significant service disruption in the past year. While the issue affected a relatively small portion of our customer base, it had a material impact on those customers, with disruptions lasting more than an hour for some workflows. We are acutely aware that for the customers affected, the scope of the impact matters far more than the size of the cohort.
We are extremely embarrassed by this failure. At the same time, we believe it is important to provide full transparency: even with this incident, Files.com continued to meet and exceed its contractual SLA commitments for the month. That fact does not lessen the seriousness of the disruption, but it does highlight the overall resilience of the platform and our ongoing investment in reliability.
We recognize that many customers depend on Remote Server Mounts for time- critical and business-critical workflows, and that any interruption is unacceptable. We sincerely apologize for the disruption this incident caused and for the impact to your operations. We take this failure seriously and are committed to maintaining the level of reliability and trust you expect from Files.com. If you have any questions or would like to discuss this incident further, our Support team stands ready to assist.