Snapshot 203035
Raw (normalized text)
Scripts and page chrome removed; this is what change detection compares.
{
"components": [
{
"created_at": "2019-05-14T05:27:02.577-07:00",
"description": null,
"group_id": null,
"id": "2rf80ygvk9dj",
"name": "Core Services / API",
"page_id": "qcl58pn3j90b",
"position": 1,
"showcase": true,
"start_date": null,
"status": "operational",
"updated_at": "2026-05-26T07:14:49.119-07:00"
},
{
"created_at": "2019-05-14T05:25:06.620-07:00",
"description": null,
"group_id": null,
"id": "tybq4br2s92c",
"name": "Web Interface",
"page_id": "qcl58pn3j90b",
"position": 3,
"showcase": true,
"start_date": null,
"status": "operational",
"updated_at": "2025-08-04T11:48:57.820-07:00"
},
{
"created_at": "2019-05-14T05:26:12.203-07:00",
"description": null,
"group_id": null,
"id": "yhzmwcrby2c0",
"name": "FTP/FTPS",
"page_id": "qcl58pn3j90b",
"position": 4,
"showcase": true,
"start_date": null,
"status": "operational",
"updated_at": "2025-07-24T10:45:10.994-07:00"
},
{
"created_at": "2019-05-14T05:26:25.603-07:00",
"description": null,
"group_id": null,
"id": "gydt7xp6ynxh",
"name": "SFTP",
"page_id": "qcl58pn3j90b",
"position": 5,
"showcase": true,
"start_date": null,
"status": "operational",
"updated_at": "2025-02-18T11:52:20.530-08:00"
},
{
"created_at": "2019-05-14T05:26:36.172-07:00",
"description": null,
"group_id": null,
"id": "d60k6d2bgz14",
"name": "WebDAV",
"page_id": "qcl58pn3j90b",
"position": 6,
"showcase": true,
"start_date": null,
"status": "operational",
"updated_at": "2024-11-20T08:37:31.071-08:00"
},
{
"created_at": "2019-05-14T05:27:16.326-07:00",
"description": null,
"group_id": null,
"id": "64yrj84k5ctd",
"name": "Background Jobs, including Sync and Webhooks",
"page_id": "qcl58pn3j90b",
"position": 7,
"showcase": true,
"start_date": null,
"status": "operational",
"updated_at": "2024-01-29T12:52:22.915-08:00"
},
{
"created_at": "2021-10-07T08:48:12.563-07:00",
"description": null,
"group_id": null,
"id": "zyn4ld98vkg3",
"name": "Remote Server Integrations (Sync and Mount)",
"page_id": "qcl58pn3j90b",
"position": 8,
"showcase": true,
"start_date": "2021-09-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2026-09-23T07:11:43.503-07:00"
},
{
"created_at": "2023-04-07T10:46:17.989-07:00",
"description": "Files-specific tools for accessing files including mobile app, desktop app, CLI, and SDKs.",
"group_id": null,
"id": "07tzmnq0fmtn",
"name": "Files Tools",
"page_id": "qcl58pn3j90b",
"position": 9,
"showcase": true,
"start_date": "2023-04-07T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2023-04-07T11:57:44.265-07:00"
},
{
"created_at": "2023-05-08T13:40:05.575-07:00",
"description": "Files and services served by the US East region.",
"group_id": null,
"id": "lbmgb8zfxn62",
"name": "USA Region",
"page_id": "qcl58pn3j90b",
"position": 10,
"showcase": true,
"start_date": "2023-05-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2026-11-02T14:32:01.803-08:00"
},
{
"created_at": "2023-05-08T13:40:33.119-07:00",
"description": null,
"group_id": null,
"id": "j481bl326xx5",
"name": "Canada Region",
"page_id": "qcl58pn3j90b",
"position": 11,
"showcase": true,
"start_date": "2023-05-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2024-09-10T04:19:17.065-07:00"
},
{
"created_at": "2023-05-08T13:40:51.099-07:00",
"description": null,
"group_id": null,
"id": "pv3fn5ydx3tb",
"name": "Australia Region",
"page_id": "qcl58pn3j90b",
"position": 12,
"showcase": true,
"start_date": "2023-05-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2024-09-10T04:19:17.073-07:00"
},
{
"created_at": "2023-05-08T13:42:43.975-07:00",
"description": null,
"group_id": null,
"id": "yh2g097v9z6t",
"name": "EU (Germany) Region",
"page_id": "qcl58pn3j90b",
"position": 13,
"showcase": true,
"start_date": "2023-05-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2024-09-10T04:19:17.082-07:00"
},
{
"created_at": "2023-05-08T13:43:01.517-07:00",
"description": null,
"group_id": null,
"id": "94sx0xpjjv3b",
"name": "UK Region",
"page_id": "qcl58pn3j90b",
"position": 14,
"showcase": true,
"start_date": "2023-05-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2025-01-18T07:33:42.842-08:00"
},
{
"created_at": "2023-05-08T13:43:19.943-07:00",
"description": null,
"group_id": null,
"id": "zk85wrq7x5zy",
"name": "Japan Region",
"page_id": "qcl58pn3j90b",
"position": 15,
"showcase": true,
"start_date": "2023-05-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2024-09-10T04:19:17.098-07:00"
},
{
"created_at": "2023-05-08T13:43:40.825-07:00",
"description": null,
"group_id": null,
"id": "wh8v439s1f0m",
"name": "Singapore Region",
"page_id": "qcl58pn3j90b",
"position": 16,
"showcase": true,
"start_date": "2023-05-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2024-11-25T00:57:25.284-08:00"
}
],
"incidents": [
{
"components": [],
"created_at": "2026-11-02T14:00:00.000-08:00",
"id": "kxsybm77t49x",
"impact": "none",
"impact_override": null,
"incident_updates": [
{
"affected_components": null,
"body": "Between 20:37 and 21:37 UTC, a small percentage of uploads to Files.com native storage failed in our primary USA region. Downloads, logins, and directory listings were not affected. This issue has been resolved.",
"created_at": "2026-11-02T14:30:42.107-08:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-11-02T14:00:00.000-08:00",
"id": "9jxxs474223b",
"incident_id": "kxsybm77t49x",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-11-02T14:30:42.107-08:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "US Region: Elevated rate of upload failures to Files.com native storage",
"page_id": "qcl58pn3j90b",
"postmortem_body": null,
"postmortem_body_last_updated_at": null,
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": null,
"reminder_intervals": null,
"resolved_at": "2026-11-02T14:00:00.000-08:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/przyr67c7yrm",
"started_at": "2026-11-02T14:30:42.044-08:00",
"status": "resolved",
"updated_at": "2026-11-02T14:30:42.117-08:00"
},
{
"components": [
{
"created_at": "2021-10-07T08:48:12.563-07:00",
"description": null,
"group_id": null,
"id": "zyn4ld98vkg3",
"name": "Remote Server Integrations (Sync and Mount)",
"page_id": "qcl58pn3j90b",
"position": 8,
"showcase": true,
"start_date": "2021-09-01T00:00:00.000-07:00",
"status": "operational",
"updated_at": "2026-09-23T07:11:43.503-07:00"
}
],
"created_at": "2026-09-23T06:17:37.784-07:00",
"id": "c8l9wxcbn4sf",
"impact": "minor",
"impact_override": null,
"incident_updates": [
{
"affected_components": [
{
"code": "zyn4ld98vkg3",
"name": "Remote Server Integrations (Sync and Mount)",
"new_status": "operational",
"old_status": "degraded_performance"
}
],
"body": "We have resolved an incident which caused delays to Syncs. This incident lasted from 12:20pm UTC to 2:08pm UTC. All Syncs that were delayed have resumed as of 2:08pm UTC.",
"created_at": "2026-09-23T07:11:43.526-07:00",
"custom_tweet": null,
"deliver_notifications": true,
"display_at": "2026-09-23T07:11:43.000-07:00",
"id": "xc5b7r2v1kzn",
"incident_id": "c8l9wxcbn4sf",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-09-23T07:35:27.443-07:00",
"wants_twitter_update": false
},
{
"affected_components": [
{
"code": "zyn4ld98vkg3",
"name": "Remote Server Integrations (Sync and Mount)",
"new_status": "degraded_performance",
"old_status": "degraded_performance"
}
],
"body": "We have identified the cause of the delays to Sync operations, and are currently remediating the issue. We expect the delayed Syncs to begin to run again shortly. No other Files.com services are affected.",
"created_at": "2026-09-23T06:25:31.637-07:00",
"custom_tweet": null,
"deliver_notifications": true,
"display_at": "2026-09-23T06:25:31.637-07:00",
"id": "gpzg9v1dmynt",
"incident_id": "c8l9wxcbn4sf",
"status": "identified",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-09-23T06:25:31.637-07:00",
"wants_twitter_update": false
},
{
"affected_components": [
{
"code": "zyn4ld98vkg3",
"name": "Remote Server Integrations (Sync and Mount)",
"new_status": "degraded_performance",
"old_status": "operational"
}
],
"body": "We are investigating reports of delays to Syncs. Other Files.com services are not affected.",
"created_at": "2026-09-23T06:17:37.866-07:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-09-23T06:17:37.866-07:00",
"id": "df986l5pr1nj",
"incident_id": "c8l9wxcbn4sf",
"status": "investigating",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-09-23T06:17:37.866-07:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "Syncs Delayed",
"page_id": "qcl58pn3j90b",
"postmortem_body": "From 12:20 PM UTC through 2:08 PM UTC on September 23, 2026, [Files.com](http://Files.com) Syncs did not run. Syncs scheduled or triggered during this window were delayed. When service was restored, every delayed Sync resumed on its own and the backlog cleared within minutes\n\nThis incident was limited to Syncs. All other [Files.com](http://Files.com) services operated normally.\n\nThe incident was caused by an incorrectly configured database schema update \\(DDL\\) operation that resulted in unintended locking to a critical database table used to coordinate sync runs.\n\nOur database migration process is generally designed to perform schema updates in a zero-downtime manner, and we do database schema updates several times per week without incident as a routine operation.\n\nThe schema update finished at 2:08 PM UTC and Syncs resumed immediately.\n\nWe are making several changes as a result of this incident, including improving the logic we use to detect database changes that would cause disruptive locking, so a change like this one fails safely in the future.\n\nMany of our customers rely on Syncs to keep critical files moving between their systems and their partners. We know a nearly two-hour delay can hold up real work, and we are sorry.\n\nWe promise a system that works perfectly, all of the time, and today we failed to deliver that to you. 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.",
"postmortem_body_last_updated_at": "2026-09-30T14:08:43.293-07:00",
"postmortem_ignored": false,
"postmortem_notified_subscribers": true,
"postmortem_notified_twitter": false,
"postmortem_published_at": "2026-09-30T14:08:43.293-07:00",
"reminder_intervals": null,
"resolved_at": "2026-09-23T07:11:43.000-07:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/sm1lvzm1h8mc",
"started_at": "2026-09-23T07:11:43.000-07:00",
"status": "resolved",
"updated_at": "2026-09-30T14:08:43.316-07:00"
},
{
"components": [],
"created_at": "2026-06-05T08:00:00.000-07:00",
"id": "y6z79vnjhl99",
"impact": "minor",
"impact_override": "minor",
"incident_updates": [
{
"affected_components": null,
"body": "We resolved an incident on the Files.com platform that caused SFTP logins using ed25519 SSH keys for authentication to fail. \n\nThis 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.\n\nThis 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.\n\nWe will provide a detailed postmortem and RCA for this incident.",
"created_at": "2026-06-05T10:51:02.987-07:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-06-05T08:00:00.000-07:00",
"id": "tzybtlkztv18",
"incident_id": "y6z79vnjhl99",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-06-05T10:51:02.987-07:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "SFTP Login Failures for ed25519 key-based authentication only in all regions",
"page_id": "qcl58pn3j90b",
"postmortem_body": "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.\n\nWe 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.\n\nWe 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.\n\nIn 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.\n\nWe 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.\n\nWe 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.\n\nThe 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.\n\nOur 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.",
"postmortem_body_last_updated_at": "2026-06-08T14:23:47.980-07:00",
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": "2026-06-08T08:11:01.459-07:00",
"reminder_intervals": null,
"resolved_at": "2026-06-05T08:00:00.000-07:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/k06cmc4qmt06",
"started_at": "2026-06-05T10:51:02.938-07:00",
"status": "resolved",
"updated_at": "2026-06-08T14:23:47.984-07:00"
},
{
"components": [],
"created_at": "2026-05-26T07:06:35.000-07:00",
"id": "2wt13cf5f33r",
"impact": "none",
"impact_override": null,
"incident_updates": [
{
"affected_components": null,
"body": "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.\n\nWe apologize for the inconvenience. A full postmortem will be published here once available.",
"created_at": "2026-05-26T07:08:15.001-07:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-05-26T07:06:35.000-07:00",
"id": "4ml1cdp6m0qq",
"incident_id": "2wt13cf5f33r",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-05-26T07:12:33.648-07:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "Uploads, create, update and delete operations failures",
"page_id": "qcl58pn3j90b",
"postmortem_body": "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.\n\n 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.\n\n [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.\n\n 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.\n\n 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.",
"postmortem_body_last_updated_at": "2026-07-28T05:21:36.264-07:00",
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": "2026-07-28T05:21:36.264-07:00",
"reminder_intervals": null,
"resolved_at": "2026-05-26T07:06:35.000-07:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/6svkxh1mvhvp",
"started_at": "2026-05-26T07:06:35.000-07:00",
"status": "resolved",
"updated_at": "2026-07-28T05:21:36.284-07:00"
},
{
"components": [],
"created_at": "2026-04-01T10:30:00.000-07:00",
"id": "cs5t9kkxz41n",
"impact": "major",
"impact_override": "major",
"incident_updates": [
{
"affected_components": null,
"body": "We have resolved an SSL certificate configuration issue affecting a subset of servers in our USA region.\n\nThis 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.\n\nWe are still in the process of determining the exact scope of impact.",
"created_at": "2026-04-01T11:12:41.721-07:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-04-01T10:30:00.000-07:00",
"id": "fkthxktph33p",
"incident_id": "cs5t9kkxz41n",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-04-01T12:18:32.840-07:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "Elevated Errors – USA Region",
"page_id": "qcl58pn3j90b",
"postmortem_body": "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.\n\nCustomers whose traffic was routed to unaffected hosts experienced no issues; others saw login timeouts or \"invalid password\" messages.\n\n**What Happened** \nWhile 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 \nload-balanced evenly, some customer sessions failed while others succeeded, making the issue difficult to detect on global dashboards.\n\nWe 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.\n\nRecent 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.\n\n**What We Have Done To Mitigate This In The Future** \nWe have updated our certificate generation to avoid the accidental omission of wildcard entries through additional validation.\n\nWe have added an additional monitoring check that which continuously verifies deployed certificates on every public endpoint for the correct wildcard entries.\n\nWe have documented the certificate-rotation mechanism and emergency override procedure in \nour internal documentation.\n\nWe 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.",
"postmortem_body_last_updated_at": "2026-04-08T11:22:29.931-07:00",
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": "2026-04-08T11:22:29.931-07:00",
"reminder_intervals": null,
"resolved_at": "2026-04-01T10:30:00.000-07:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/tm2kcngdtfpn",
"started_at": "2026-04-01T10:30:00.000-07:00",
"status": "resolved",
"updated_at": "2026-04-08T11:22:29.957-07:00"
},
{
"components": [],
"created_at": "2026-02-10T10:30:00.000-08:00",
"id": "dhqpm32h66kn",
"impact": "none",
"impact_override": null,
"incident_updates": [
{
"affected_components": null,
"body": "We have resolved an incident causing failures to load the Files.com Editor in our web interface.\n\nThis incident occurred between the times of approximately 18:20 to 19:23 UTC on February 10th.\n\nOffice documents can once again be previewed and edited in the built-in Files.com Editor.\n\nWe 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.",
"created_at": "2026-02-10T12:27:19.754-08:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-02-10T10:30:00.000-08:00",
"id": "yyx4b8h01kcx",
"incident_id": "dhqpm32h66kn",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-02-10T12:27:19.754-08:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "Failures loading the Files.com Editor",
"page_id": "qcl58pn3j90b",
"postmortem_body": "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.\n\n \n\n**What happened**\n\nOur 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.\n\n \n\n**What we found**\n\n* 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”.\n\n* Our Consul monitoring treated any HTTP 200 as healthy, so no automatic alert fired.\n\n* This same chain of events occurred on 20 January but was not fully remediated.\n\n \n\n**What we are doing**\n\n1. Updating the Consul health check to validate the response body and fail closed when the editor reports “false”.\n2. Enabling CloudWatch logs and metrics for Amazon MQ and alerting on broker restarts and AMQP channel errors.\n3. Adding an integration test that continuously opens and saves a document in production and pages engineering if it stalls.\n4. 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.\n\n \n\nWe 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).",
"postmortem_body_last_updated_at": "2026-04-08T11:25:35.023-07:00",
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": "2026-04-08T11:25:35.023-07:00",
"reminder_intervals": null,
"resolved_at": "2026-02-10T10:30:00.000-08:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/wtfk7bv828jy",
"started_at": "2026-02-10T12:27:19.699-08:00",
"status": "resolved",
"updated_at": "2026-04-08T11:25:35.044-07:00"
},
{
"components": [],
"created_at": "2026-01-20T11:44:23.947-08:00",
"id": "tqs9ttp4lp72",
"impact": "none",
"impact_override": null,
"incident_updates": [
{
"affected_components": null,
"body": "We have resolved an incident causing failures to load the Files.com Editor in our web interface. \n\nThis incident was resolved at 19:45 UTC on January 20th. \n\nOffice documents can once again be previewed and edited in the built-in Files.com Editor. \n\nWe 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.",
"created_at": "2026-01-20T12:02:09.360-08:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-01-20T12:02:09.360-08:00",
"id": "73f1hj9zcwcp",
"incident_id": "tqs9ttp4lp72",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-01-20T12:02:09.360-08:00",
"wants_twitter_update": false
},
{
"affected_components": null,
"body": "We are investigating an incident causing failures to load the Files.com Editor in our web interface.\n\nThis incident only impacts the built-in Files.com Editor for previewing and editing Office documents. This incident does not impact the previewing of images, PDFs, or plaintext files, and this incident does not impact customers using the Microsoft Office editor.\n\nCustomers who need to urgently view or edit Office documents can still download those documents locally.\n\nWe will post updates to this incident as we have them.",
"created_at": "2026-01-20T11:44:23.986-08:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-01-20T11:44:23.986-08:00",
"id": "k1c8tlxxr2yv",
"incident_id": "tqs9ttp4lp72",
"status": "investigating",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-01-20T11:44:23.986-08:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "Failures loading the Files.com Editor",
"page_id": "qcl58pn3j90b",
"postmortem_body": null,
"postmortem_body_last_updated_at": null,
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": null,
"reminder_intervals": null,
"resolved_at": "2026-01-20T12:02:09.360-08:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/0ymbcb9090hz",
"started_at": "2026-01-20T11:44:23.941-08:00",
"status": "resolved",
"updated_at": "2026-01-20T12:02:09.378-08:00"
},
{
"components": [],
"created_at": "2026-01-09T08:00:00.000-08:00",
"id": "mn4dxs1bvxhk",
"impact": "none",
"impact_override": null,
"incident_updates": [
{
"affected_components": null,
"body": "We have resolved an issue which caused upload and download failures for customers using both Custom Domains and Remote Server Mounts.\n\nFrom 16:14 to 16:28 UTC, Customers using both Custom Domains and Remote Server Mounts experienced failures in uploads and downloads to those folders on a Remote Server Mount. These failures manifested as Internal Server Error messages or similar messages on other protocols. Additionally from 21:45 to 22:55 UTC a smaller subset of customers using both Custom Domains and Remote Server Mounts experienced failures in uploads (but not downloads).\n\nThis incident only affected remote server mounts, and only affected sites with Custom Domains.\n\nWe understand that many customers rely on Remote Server Mounts for time-critical workflows, and even a brief interruption is unacceptable. We apologize for the disruption and appreciate your continued trust in Files.com. If you have any questions, please reach out to our Support team at any time.",
"created_at": "2026-01-09T08:51:34.698-08:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2026-01-09T15:45:00.000-08:00",
"id": "dv0hxfm6mypv",
"incident_id": "mn4dxs1bvxhk",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2026-01-09T15:56:08.281-08:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "Sites with Custom Domains only: Failures Uploading and downloading to Remote Server Mounts",
"page_id": "qcl58pn3j90b",
"postmortem_body": "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](http://Files.com) Agent- backed connections.\n\nA code change in the [Files.com](http://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.\n\nThese 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.\n\nAlthough 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.\n\nThe 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.\n\nWe 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.\n\nThis 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.\n\nWe 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](http://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.\n\nWe 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](http://Files.com). If you have any questions or would like to discuss this incident further, our Support team stands ready to assist.",
"postmortem_body_last_updated_at": "2026-01-22T15:51:01.513-08:00",
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": "2026-01-22T15:51:01.513-08:00",
"reminder_intervals": null,
"resolved_at": "2026-01-09T15:45:00.000-08:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/2mw3w2dr7s8f",
"started_at": "2026-01-09T15:45:00.000-08:00",
"status": "resolved",
"updated_at": "2026-01-22T15:51:01.539-08:00"
},
{
"components": [],
"created_at": "2025-11-25T05:23:00.000-08:00",
"id": "c5chr9yykcn9",
"impact": "none",
"impact_override": null,
"incident_updates": [
{
"affected_components": null,
"body": "We have resolved an issue which caused elevated error rates in outbound connections from Files.com to Sharepoint and OneDrive remote servers. \n\nThe impact was limited to these two remote server integrations and did not impact any inbound connections to Files.com that don’t involve Onedrive or SharePoint remote servers. This incident occurred between the times of 1:23PM and 2:58PM UTC.",
"created_at": "2025-11-25T07:40:25.219-08:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2025-11-25T05:23:00.000-08:00",
"id": "7z31c0t4bdfp",
"incident_id": "c5chr9yykcn9",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2025-11-25T07:40:25.219-08:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "Outbound Connections to Sharepoint and OneDrive: Elevated Error Rates",
"page_id": "qcl58pn3j90b",
"postmortem_body": null,
"postmortem_body_last_updated_at": null,
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": null,
"reminder_intervals": null,
"resolved_at": "2025-11-25T05:23:00.000-08:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/fnxl2k67l3kd",
"started_at": "2025-11-25T07:40:25.171-08:00",
"status": "resolved",
"updated_at": "2025-11-25T07:40:25.230-08:00"
},
{
"components": [
{
"created_at": "2019-05-14T05:25:06.620-07:00",
"description": null,
"group_id": null,
"id": "tybq4br2s92c",
"name": "Web Interface",
"page_id": "qcl58pn3j90b",
"position": 3,
"showcase": true,
"start_date": null,
"status": "operational",
"updated_at": "2025-08-04T11:48:57.820-07:00"
}
],
"created_at": "2025-08-04T05:28:32.000-07:00",
"id": "m22d2j637l0g",
"impact": "minor",
"impact_override": "minor",
"incident_updates": [
{
"affected_components": [
{
"code": "tybq4br2s92c",
"name": "Web Interface",
"new_status": "operational",
"old_status": "operational"
}
],
"body": "Google has reviewed our appeal of this issue and acknowledged that this was a false positive. There was never any danger to any users connecting to any Files.com site. This issue is now resolved.\n\nStarting this morning, we began to receive reports from customers that users accessing Files.com through Google Chrome, Mozilla Firefox, Safari, or other browsers that rely on Google’s Safe Browsing were erroneously seeing a \"Dangerous Site\" warning.\n\nGoogle has removed Files.com from its list of \"Dangerous Sites\" and our testing indicates that browsers are no longer displaying this erroneous warning.\n\nIf you or your users are still seeing a warning when navigating to your Files.com site, you likely need to wait a little longer for your browsers to receive an update from Google.",
"created_at": "2025-08-04T14:09:42.113-07:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2025-08-04T14:09:42.113-07:00",
"id": "f2xyx7w400s3",
"incident_id": "m22d2j637l0g",
"status": "resolved",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2025-08-04T14:09:42.113-07:00",
"wants_twitter_update": false
},
{
"affected_components": [
{
"code": "tybq4br2s92c",
"name": "Web Interface",
"new_status": "operational",
"old_status": "partial_outage"
}
],
"body": "We are continuing to investigate this issue.",
"created_at": "2025-08-04T11:48:21.701-07:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2025-08-04T11:48:21.701-07:00",
"id": "0cp82fh7z075",
"incident_id": "m22d2j637l0g",
"status": "investigating",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2025-08-04T11:48:21.701-07:00",
"wants_twitter_update": false
},
{
"affected_components": [
{
"code": "tybq4br2s92c",
"name": "Web Interface",
"new_status": "partial_outage",
"old_status": "partial_outage"
}
],
"body": "This issue specifically affects the Files.com login page when it is accessed directly, at a URL formatted like domain.files.com/login. This usually only occurs when the login page is bookmarked.\n\nUsers can navigate directly to their domain (for example, by accessing domain.files.com instead of domain.files.com/login) without receiving this warning.\n\nWe will update this page again only when new information becomes available.",
"created_at": "2025-08-04T07:22:38.747-07:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2025-08-04T07:22:38.747-07:00",
"id": "g79yzfy7kvzm",
"incident_id": "m22d2j637l0g",
"status": "investigating",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2025-08-04T07:22:38.747-07:00",
"wants_twitter_update": false
},
{
"affected_components": [
{
"code": "tybq4br2s92c",
"name": "Web Interface",
"new_status": "partial_outage",
"old_status": "operational"
}
],
"body": "We’ve received reports from customers that users accessing their site through Google Chrome, Mozilla Firefox, Safari, or other browsers that rely on Google’s Safe Browsing are erroneously seeing a \"Dangerous Site\" warning. \n\nThis issue specifically affects the Files.com login page when it is accessed directly, at a URL formatted like domain.files.com/login. This usually only occurs when the login page is bookmarked.\n\nUsers can navigate directly to their domain (for example, by accessing domain.files.com instead of domain.files.com/login) without receiving this warning.\n\nWe believe that this may have been caused by one of our customers falsely reporting to Google that their Files.com site was unsanctioned. We are attempting to work with Google to have them review the report.\n\nThere is no security concern with the Files.com application, and you should disregard this error.\n\nPlease help us by submitting a report to Google that this page is safe: https://safebrowsing.google.com/safebrowsing/report_error/?url=https:%2F%2Ffiles.com%2Flogin\u0026hl=en-US\n\nWhen writing your report, please fill in your custom subdomain in the URL box.\n\nWe will provide additional details as they become available. Customers with urgent questions are encouraged to contact our Customer Support team by email. Thank you for your patience.",
"created_at": "2025-08-04T05:28:32.171-07:00",
"custom_tweet": null,
"deliver_notifications": false,
"display_at": "2025-08-04T05:28:32.000-07:00",
"id": "tds4zxjs1m0r",
"incident_id": "m22d2j637l0g",
"status": "investigating",
"tweet_id": null,
"twitter_updated_at": null,
"updated_at": "2025-08-04T06:33:12.067-07:00",
"wants_twitter_update": false
}
],
"metadata": {},
"monitoring_at": null,
"name": "Google Safe Browsing is falsely reporting the Files.com login page as a \"Dangerous Site\" if it is navigated to directly",
"page_id": "qcl58pn3j90b",
"postmortem_body": "From 10:03 UTC to 19:02 UTC on August 4, 2025, some users attempting to sign in to [Files.com](http://Files.com) via URLs ending in /login \\(e.g., [acme.files.com/login](http://acme.files.com/login)\\) encountered a red warning stating “Deceptive site ahead.”\n\nThis warning appeared in Chrome, Safari, Firefox, and other browsers that rely on Google Safe Browsing.\n\nAffected access paths included: \n\n* Bookmarked links to /login \n* Direct navigation to /login \n* The \"Sign In\" button on our marketing website\n\nAll other product surfaces—including APIs, desktop and CLI apps, agents, mobile apps, custom domains, and already-loaded web app sessions—remained fully functional and unaffected. \n\n**Root Cause** \n\nThe Chrome, Safari, and Firefox browsers all use a service from Google called Google Safe Browsing to identify potentially dangerous sites and apply a full page warning when a user tries to visit any site that has been flagged by Google Safe Browsing.\n\nThe [Files.com](http://Files.com) subdomain for a [Files.com](http://Files.com) customer was incorrectly reported to Google Safe Browsing as a phishing site by a third-party security vendor affiliated with that customer. \n\nGoogle accepted the report without independent validation and—unexpectedly— applied a warning to any login page on the entire [files.com](http://files.com) domain, not just that specific customer subdomain. \n\nTo be clear:\n\n* No malware was present. \n* No compromise occurred. \n* No policy violation took place on the [Files.com](http://Files.com) platform.\n\nWe have identified both the customer and the third-party vendor responsible for the report and have taken action to prevent any recurrence. \n\n**Response Timeline** \n\nAt 10:09 UTC, our team convened an incident bridge within six minutes of detection and posted a status page update. \n\nShortly after: \n\n* We disabled the affected customer’s subdomain. \n* We submitted a formal appeal to Google via Search Console, providing logs and proof that the report was a false positive. \n* We pushed a change to reroute new login sessions from /login to /newsession, restoring access for all customers except those with bookmarks to the previous URL. \n* We requested “This site is safe” confirmations from affected customers to help expedite Google’s manual review. \n\nAt 19:02 UTC Google completed its review and removed the incorrect classification. Browser warnings began disappearing shortly thereafter as Safe Browsing lists refreshed \\(typically within 30–60 minutes\\). \n\n**Our Perspective** \n\nWe understand the critical nature of [Files.com](http://Files.com) in your workflows, and we consider this incident wholly unacceptable—not because of any fault in our systems, but because access to our login page was unfairly blocked, creating real-world disruption for our customers and reputational damage for both you and us. \n\nWe are deeply frustrated by how this situation was handled by Google: \n\n* An erroneous third-party report—submitted via a poorly governed “security” company system—was accepted by Google without any review. \n* Worse, the impact of that report was applied far beyond its scope, extending the warning to our entire domain, rather than the single customer subdomain in question. \n* Despite escalating through multiple internal and public channels, it took Google over 9 hours to act, during which time countless users encountered misleading and damaging warnings when trying to access [Files.com](http://Files.com). \n\nThis incident reveals a deeply troubling reality: Google Safe Browsing wields extraordinary power over the web, but operates with little transparency, no meaningful appeals process, and effectively zero accountability. There’s no SLA, no phone number, and no obligation to fix their own errors promptly—if at all.\n\nWe believe this system is broken. A single bad report—no matter how inaccurate— can cause cascading damage to legitimate businesses without recourse. That’s not just frustrating. It’s dangerous.\n\nWe’re currently working to establish a more reliable escalation path within Google Safe Browsing, but the truth is: no business should have to navigate this kind of opaque and unilateral system to protect its integrity.\n\nWe sincerely apologize for the disruption and appreciate your patience and trust. If you have any further questions or concerns, please reach out to our Support team.",
"postmortem_body_last_updated_at": "2025-08-18T07:55:10.712-07:00",
"postmortem_ignored": false,
"postmortem_notified_subscribers": false,
"postmortem_notified_twitter": false,
"postmortem_published_at": "2025-08-18T07:55:10.712-07:00",
"reminder_intervals": null,
"resolved_at": "2025-08-04T14:09:42.113-07:00",
"scheduled_auto_completed": false,
"scheduled_auto_in_progress": false,
"scheduled_for": null,
"scheduled_remind_prior": false,
"scheduled_reminded_at": null,
"scheduled_until": null,
"shortlink": "https://stspg.io/y9vt2m7c8b59",
"started_at": "2025-08-04T05:28:32.000-07:00",
"status": "resolved",
"updated_at": "2025-08-18T07:55:10.734-07:00"
}
],
"page": {
"id": "qcl58pn3j90b",
"name": "Files.com",
"url": "https://status.files.com"
},
"status": {
"description": "All Systems Operational",
"indicator": "none"
}
}