When Meta went dark twice in the span of 72 hours in late July 2026, the story was not really about Facebook, Instagram, or WhatsApp. It was about what happens inside an engineering organization when the same class of failure comes back before the ink on the first retrospective has dried. For anyone who owns reliability, this is the sharpest possible reminder that on-call incident response is not a checkbox you complete once. It is a living practice that either compounds in your favor or quietly rots between pages. The second outage in a short window is the moment that separates teams who learned from teams who merely survived.
On Wednesday, July 22, 2026, millions of users worldwide were logged out, greeted with "account temporarily unavailable" messages, and unable to refresh feeds or send messages. The disruption began around 1:00 p.m. GMT and resolved within one to two hours. What made it notable was not the duration but the recurrence: it was the second time in 72 hours that Meta's flagship platforms had stumbled, following a smaller wave of reports on July 19. Early analysis from outside observers pointed at DNS resolution as a likely culprit, the same category of failure that has felled countless services before. Meta did not immediately publish a confirmed root cause, which is itself a lesson worth sitting with.
We are not writing this to dunk on Meta. Every team of sufficient scale ships incidents. The interesting question for the rest of us is operational: when a failure recurs, what does that say about the on-call and incident-management muscle behind the scenes, and how do you build a practice that turns a first incident into a permanent fix rather than a recurring tax? Below we break down what repeat outages reveal, why DNS keeps humbling mature teams, and the concrete on-call habits that shorten the gap between detection and durable resolution.
The first time a system fails in a new way, it is a discovery. Nobody had a runbook for it because nobody had seen it. The team scrambles, forms a bridge, finds the problem, mitigates, and writes it up. That is normal and, in a sense, healthy. Incidents are how complex systems teach you where their edges are.
The second time the same failure class shows up is a different kind of signal. It tells you something about the loop between an incident and the changes it was supposed to trigger. Did the first retrospective produce action items, or just a narrative? Were those action items assigned owners and deadlines, or did they evaporate into a backlog? Did the fix address the proximate cause only, or the conditions that allowed the proximate cause to matter? When the same category of outage recurs within days, it usually means the remediation work was still in flight, was deprioritized, or was never scoped correctly in the first place.
This is why seasoned reliability leaders pay so much attention to what happens after the all-clear. Mean time to resolution gets the headlines, but the metric that predicts your next bad week is closer to "mean time to durable remediation." A team can have excellent detection and fast mitigation and still be fragile if the learning loop is broken. Repeat outages are the visible symptom of an invisible process failure.
A blameless postmortem that generates ten insightful action items and zero completed changes is worse than useless, because it creates the comforting illusion of progress. The discipline that matters is boring: every action item gets an owner, a due date, and a tracking mechanism that surfaces it until it is done. If your retrospective template ends when the document is written, you have built a system that documents fragility rather than removing it.
The practical fix is to treat remediation items with the same seriousness as customer-facing features. They belong in the same planning process, they get sized, and they get a place on the roadmap. When a remediation item slips, that slip should be visible to the people who will be paged if the underlying issue recurs. Closing that visibility gap is one of the highest-leverage things an on-call organization can do.
The suspected DNS angle in the Meta episode is worth dwelling on because DNS is the archetypal example of a dependency that is simultaneously invisible and load-bearing. When DNS resolution fails, applications do not throw a clean, obvious error. They hang, they time out, they retry in ways that amplify load, and they produce symptoms three layers away from the actual cause. Engineers end up chasing application errors, database latency, and load balancer health while the real problem sits in name resolution.
DNS is not alone in this. The same pattern shows up with expired certificates, configuration pushes that propagate globally before anyone notices, feature flags flipped without a blast-radius plan, and control-plane changes that cascade into the data plane. Just days before the Meta episode, a configuration file that failed to load inside Amazon CloudFront took a large slice of the internet offline for over three hours. The lesson repeats: the most damaging outages rarely come from exotic hardware failures. They come from mundane changes to shared, foundational systems that everything else quietly depends on.
For on-call teams, the takeaway is not "monitor DNS harder," though you should. It is that your incident response has to be built to find the cause quickly when the symptoms are misleading. That means a few specific capabilities:
Every incident has a fragile opening window. In the first ten minutes, the responder is trying to answer three questions at once: is this real, how bad is it, and who needs to be here. If those questions take too long to answer, the incident inflates. Customers pile onto status pages, executives start asking for updates, and the responder is now doing crisis communication instead of debugging.
This is where the mechanics of your on-call setup matter enormously. A page that reaches the right person on the first try, with enough context to orient them, buys back minutes that compound. A page that goes to someone who cannot act, or that arrives without context, forces a second escalation and a cold start. Multiply that across a multi-team incident and you understand why some organizations resolve in twenty minutes what takes others two hours.
Escalation policies fail quietly. They look fine on paper: primary, secondary, then the manager. In practice, the primary is on a flight, the secondary changed phone numbers, and the manager's notifications are muted. The only way to know your escalation path works is to exercise it, both in drills and by reviewing real incidents for cases where the page bounced. If you cannot answer "how long until an unacknowledged page reaches a human who can act," you have a gap.
Good escalation design assumes people will be unreachable and routes around them fast. It also assumes that the person who gets paged may not be the person who fixes it, so it makes bringing in additional responders frictionless. The goal is to collapse the time between "something is wrong" and "the right group of humans is in one place working the problem."
There is a romantic image of the lone engineer who parachutes into an outage and fixes it through sheer brilliance. Real reliability is less glamorous. It comes from responders who arrive with context already in hand: recent changes, related alerts, the current runbook, and a clear picture of impact. When that context is automatic, ordinary engineers resolve extraordinary incidents. When it is missing, even your best people burn the first twenty minutes just figuring out what they are looking at.
Most engineering teams already live in Slack. During an incident, that is where the conversation naturally happens, where responders coordinate, and where stakeholders watch for updates. The problem with many traditional incident tools is that they pull people out of that environment and into a separate console, adding context switches at exactly the moment when every second counts.
A Slack-native on-call tool like Pagerly closes that gap by putting the entire response loop where the work already happens. Schedules, escalations, and paging live in Slack, so acknowledging a page, pulling in a secondary responder, or checking who is on call is a message away rather than a login away. When the alert, the responders, the runbook, and the timeline all share one channel, the first ten minutes stop being a scavenger hunt.
This matters most in exactly the scenario Meta faced: a fast-moving, possibly recurring incident where speed of coordination determines whether you are down for twenty minutes or two hours. A few ways the Slack-native model helps in practice:
The point is not that a tool prevents outages. Nothing prevents outages. The point is that the coordination overhead of an incident is a cost you pay every single time, and reducing it pays back on every page for years. A team that shaves ten minutes off its average coordination time is a team that will handle its inevitable repeat incident far better than the one that does not.
If repeat outages are the symptom of a broken learning loop, the cure is to design the loop deliberately. This is less about buying the perfect tool and more about a handful of habits that, practiced consistently, turn incidents into durable improvements.
Tired, resentful responders make worse decisions and miss follow-through. Sustainable rotations, fair paging that respects sleep, and a genuine effort to reduce noisy alerts are not soft perks. They are reliability investments. An engineer who trusts that a page means something real responds faster and thinks more clearly than one who has been trained by false alarms to expect nothing. Alert fatigue is a direct contributor to slow response and to the kind of oversight that lets a first outage become a second.
Game days, chaos exercises, and simple escalation drills expose the gaps that only reveal themselves under pressure: the runbook that references a decommissioned dashboard, the escalation that dead-ends, the assumption that someone owns a service when nobody does. The teams that recover fastest are almost always the teams that have rehearsed. You do not rise to the occasion during an outage; you fall to the level of your preparation.
When remediation items are tracked where the whole team can see them, social pressure works in your favor. A remediation item that has been open for three weeks and is visible to everyone who might get paged for the underlying issue tends to get done. Buried in a private backlog, it does not. Transparency is not just a cultural nicety here; it is a mechanism that makes the learning loop actually close.
Track the obvious metrics, but pay special attention to the leading indicators of fragility: how many action items from past incidents are still open, how often pages escalate past the primary, how many alerts are acknowledged and then ignored, and how long remediation work sits before it ships. These numbers tell you whether your next repeat outage is a question of if or when.
Meta's back-to-back outages are a high-profile version of a story that plays out constantly at smaller scale. The specifics, whether DNS or configuration or something else entirely, matter less than the pattern. Here is what to carry away:
No team gets to opt out of incidents. What you get to choose is whether each one leaves you a little stronger or sets up the next one. The organizations that come out of a rough week better than they went in are not the ones with the fewest failures. They are the ones whose on-call incident response is built to learn, whose remediation actually ships, and whose responders can move fast because the tooling gets out of their way. That is the difference between an outage that becomes a war story and an outage that becomes a pattern. If your team wants to shorten the distance between a page and a durable fix, a Slack-native approach to on-call is a practical place to start, because it attacks the coordination cost you pay on every single incident.
