Slack

Slack's January 4, 2021 outage began with an overloaded managed cloud transit hub, but it did not end there. Packet loss across an AWS Transit Gateway interacted with Slack's own monitoring placement, health checks, autoscaling signals, provisioning limits and recovery controls. The result was a broad disruption on the first working day of the year for many people who had come to depend on Slack for remote work and school. The incident is therefore more useful as an accountability case than as a simple story about one cloud service failing. The factual record supports a shared-control explanation. Slack said AWS controlled the Transit Gateway's scaling and manually increased its capacity after AWS monitoring detected the problem. Slack controlled the architecture around that gateway: the VPC relationships, the monitoring path, the web tier, the provisioning service, automation rules, quotas and resource ceilings that shaped how packet loss became a prolonged service failure. Enterprise customers did not control either company's infrastructure, but they did control how much of their own operational continuity depended on one collaboration platform and what alternatives were available when it failed. That allocation does not establish legal liability, negligence or an SLA breach. It is an operational analysis based on who could observe, change, test or verify each control surface. The distinction matters. Calling the event an "AWS outage" would hide Slack's failure-amplifying conditions. Calling it solely a Slack failure would ignore the managed transit capacity that Slack could not directly increase. Calling it proof that cloud services are inherently unsafe would be broader still than the evidence permits.