The moment a major outage starts, something counterintuitive happens at most tech companies: almost nobody knows about it yet. Not because monitoring is bad—it's because the first alert usually goes to an automated system that pages an on-call engineer who's asleep, eating lunch, or in a meeting. By the time a human acknowledges it, 2-3 minutes have already passed. The company's status page still says everything is green. Customers are already tweeting. And internally, the people who could actually fix it are still being woken up.
The Alert Goes to the Wrong Person First
Most companies route initial alerts to whoever is on-call for infrastructure that week. This person might be a junior engineer, a database specialist, or someone who hasn't touched the affected system in months. They'll page their manager. Their manager will page the team lead. The team lead will page the actual expert who built the system. This relay happens over 4-5 minutes while the outage compounds. Meanwhile, the status page remains untouched because updating it requires a different person with different credentials who might not even know there's a problem yet. The gap between 'we know something is wrong' and 'we know what is wrong' is surprisingly large.
Everyone Assumes Someone Else Is Already Fixing It
Here's the non-obvious part: in minute 4-6, multiple teams are independently investigating the same outage, completely unaware of each other. The database team is checking replication. The network team is checking BGP routes. The application team is checking their recent deployments. They're all in different Slack channels or not in Slack at all—they're on calls, in Discord, in PagerDuty. The first person to post in the main incident channel often isn't the person fixing it. It's someone asking if anyone else is seeing this. This creates a strange moment where the outage is 'known' but nobody has actually started coordinating a response yet.
The Deployment Rollback Decision Happens on Incomplete Information
By minute 7-8, someone will suggest rolling back the last deployment. This is almost always the first instinct. The problem: nobody has actually confirmed whether the deployment caused the outage. But rolling back is fast (2-3 minutes) while investigating is slow (10-20 minutes). So the decision logic becomes: 'We deployed 45 minutes ago, things broke 10 minutes ago, the timing is suspicious.' They don't mention that correlation isn't causation. They roll back. Sometimes this fixes it. Sometimes it doesn't, and now they've wasted 5 minutes and the actual problem is still running. The companies that handle outages well have a predetermined escalation path that includes a 'don't rollback yet' gate. Most don't.
The Status Page Update Lags Reality by 5-10 Minutes
Customers are usually aware of the outage before the company acknowledges it publicly. This isn't because companies are hiding it—it's because the person who can update the status page (often in a different timezone or team) doesn't have real-time incident visibility. By the time someone decides 'we should tell people something is wrong,' they have to figure out what to say. 'Investigating' is safe but useless. 'We identified the issue' is premature. Meanwhile, the actual engineers fixing it are deep in logs and don't have time to write updates. The 10-minute mark is typically when the first honest status page update appears, which is 5-10 minutes after customers first noticed something was broken.
What You Can Do Right Now
If you run a service, map your incident response chain on paper today. Who gets paged first? Who can actually fix each type of outage? Who updates the status page? Write it down. Test it quarterly by running a fake outage. The companies that respond fastest don't have better engineers—they have predetermined roles and a practiced process. For monitoring, don't just rely on automated alerts. Set up alerts that page multiple people simultaneously for critical systems, not sequentially. And if you run a customer-facing service, give your status page editor real-time access to your incident channel. The 5-minute gap between reality and communication is where customer trust dies.