Good incident communication is the difference between an outage your users forgive and an outage that quietly pushes them toward a competitor. That lesson landed hard in late July 2026, when Gergely Orosz of The Pragmatic Engineer publicly walked away from publishing video podcasts on Spotify after a run of reliability failures. The bug that broke publishing was almost beside the point. What actually drove a loyal, high profile creator out the door was the silence around each incident: no public status page, delayed postmortems, and the uncomfortable fact that customers noticed the failure before Spotify's own alerts did.
If you run on-call for any product that people depend on, this story is worth ten minutes of your time. It is not really about Spotify. It is about a failure mode that shows up in nearly every engineering organization once scale and complexity outrun a reactive, alert-driven process. Below we break down what happened, why the communication gap did more damage than the outage itself, what recent industry data says about how common this problem has become, and how to build an incident communication practice that keeps trust intact when things break.
Orosz had published The Pragmatic Engineer Podcast across three platforms for two years: Substack for the master audio feed, YouTube for video, and Spotify for both. For eighteen months it mostly worked. Then, starting in late May 2026, the publishing pipeline began breaking on a near weekly cadence, always around the Wednesday publish window.
The pattern, in his own accounting, looked like this:
After outage #1, Spotify's team sent a candid private explanation: a newly introduced validation signal had not been wired into the logic that triggers the final publishing step, so eligible episodes silently failed to propagate. They identified the root cause, deployed a fix, reprocessed the affected episodes, and promised to tighten the system and improve how partial, creator impacting delays get surfaced. Those were the right words. The problem is what happened next.
The promised improvement to creator communication never materialized before outage #2 and outage #3 hit. The incident review for the 24 June outage did not arrive within the roughly two weeks it should have taken. Three weeks later, with no review in hand, stream counts trending down, and a creator portal that intermittently threw errors and 404 pages, Orosz pulled his video episodes off the platform entirely.
Every team ships bugs. Spotify reportedly pushes around 4,500 production deploys a day, and at that velocity some regressions are inevitable. The bug that broke publishing was a normal, explainable engineering mistake. What turned a normal mistake into a customer losing event was the communication vacuum around it. This is the part every on-call and incident management team should study closely, because the same vacuum forms in most organizations by default, not by intent.
When outage #2 took Spotify down for many users, there was no public status page to consult. A creator experiencing a failure could not tell whether it was a localized glitch, a regional problem, or a full platform outage. That ambiguity is corrosive. Without an authoritative place that says "yes, we know, here is what is happening and when we expect an update," every affected user is left to guess, to refresh, to tweet, and to assume the worst.
A status page is not a nicety. It is the single most efficient tool for cutting inbound support load during an incident and for signaling that a human is awake at the wheel. When you do not have one, every customer becomes an independent investigator, and their collective anxiety turns into support tickets, social posts, and churn. The absence of a status page also removes your own team's forcing function to acknowledge reality quickly and publicly.
The most damning detail came out of Spotify's eventual incident report, which acknowledged that "many creators learned something was wrong from their audiences before they heard anything from us." Read that again through an on-call lens. The people affected by the outage detected it before the internal alerting did, or at least before the company acted on it. The creator had emailed the team around 17:30 to report the outage, and the first published incident timeline downplayed that customer reports preceded the automated alerts. Only after a complaint was the timeline corrected.
This is the failure mode that quietly erodes reliability programs everywhere. Monitoring is built around the failures you already imagined. The failures that hurt most are the ones nobody instrumented, so the first signal is a human saying "this is broken." When that human is your customer rather than your alerting stack, you are already behind, and the clock on trust is running.
Spotify is not an outlier. The 2026 State of Production Reliability and AI Adoption Report, based on a February 2026 survey of 1,039 SRE, DevOps, and IT operations professionals, found that reactive, alert-driven incident response is buckling under modern scale. Two numbers from that report should stop any reliability leader in their tracks.
Put those together and a clear picture emerges. Either the alert never fires, or it fires into a stream of noise so dense that the on-call engineer has been trained to ignore it. In both cases, the outcome is identical to what Spotify's creators experienced: the customer finds out first. The report frames this as an industry at an inflection point, where bolting more alerts onto a noisy system no longer improves reliability and often makes it worse.
There is a second, quieter theme in the same research. A majority of executives said their organizations are actively using AI to address reliability, while far fewer engineers agreed. That gap between leadership narrative and frontline reality rhymes with the Spotify story, where the public conversation centered on AI adoption, thousands of daily deploys, and AI assisted pull requests, while the reliability of an existing, working product visibly degraded. Chasing the next capability while the current experience gets worse is a recognizable pattern, and it has a cost that rarely shows up on a roadmap slide.
The good news is that the fixes here are well understood and largely process driven. You do not need a research budget or a new AI platform to close most of the gap Spotify fell into. You need faster detection, a single place to communicate, and postmortems people actually trust. Here is how to approach each.
If 78 percent of organizations have shipped an incident with no alert, then the assumption that monitoring covers your critical paths is probably wrong. Treat detection as an ongoing design problem rather than a one time setup.
Once you know something is broken, the goal is to collapse the distance between detection and honest acknowledgment. Speed and single sourcing matter more than polish.
The final blow in the Spotify story was not the outage or even the silence. It was a postmortem that arrived weeks late, read as vague, and initially got the timeline wrong in a way that happened to make the company look better. Trust in a postmortem is easy to lose and hard to rebuild.
Most of the gaps in this story share a root cause: the response was fragmented and slow to reach the right humans. This is precisely the problem a Slack-native on-call and incident management tool like Pagerly is built to solve, because it puts detection, escalation, coordination, and communication in the place engineers already live.
When an alert or a customer report lands, Pagerly can page the correct on-call person directly in Slack, respecting schedules and escalation policies so a real human acknowledges within minutes rather than hours. The incident channel becomes the single source of truth: responders coordinate, the timeline is captured automatically as it happens, and there is no fragile reconstruction of events after the fact. That alone would have prevented the wrong timeline problem, because the record is written while the incident is live.
On the communication side, Pagerly's status page and incident tooling give you the public acknowledgment layer that Spotify lacked entirely. You can spin up a status page incident, keep stakeholders updated on a cadence, and close the loop with a postmortem that draws on the real, timestamped record rather than someone's memory three weeks later. Overrides, shift swaps, and reminders keep the on-call rotation healthy so the people receiving alerts are not the same exhausted engineers who have learned to ignore them. None of this replaces good engineering judgment, but it removes the friction that turns a normal bug into a trust losing event.
If you take nothing else from the Spotify episode, wire these habits into your on-call practice before your next outage forces the issue:
The uncomfortable throughline of the Spotify story is that a company can ship thousands of deploys a day, adopt AI aggressively across its engineering org, and still lose a loyal customer over the unglamorous work of communicating clearly when something breaks. Reliability is not just uptime. It is the felt experience of being told the truth quickly when the system fails you. A distinguished engineer once described lasting software success as simply "sucking less with every release." The inverse is just as true. Ship faster while the existing experience quietly degrades, and eventually even patient users run out of patience.
For on-call and DevOps teams, the takeaway is not to move slower or to fear shipping. It is to treat incident communication as a core reliability feature rather than an afterthought. Detect the failures your dashboards miss, acknowledge them in public before your customers do it for you, keep the whole response in one place, and follow through with postmortems people can trust. The outages will still happen. Whether they cost you your best users depends almost entirely on what you do in the minutes and days after.
This is exactly the kind of work a Slack-native on-call tool is meant to make routine. When paging, coordination, status updates, and the incident record all live where your engineers already work, the gap between "something is broken" and "we told our customers and fixed it" shrinks from weeks to minutes. That gap is where trust is won or lost, and it is worth engineering as deliberately as anything else you ship.
