On June 24, 2026, we experienced a disruption that delayed the publication of podcast episodes on Spotify. We want to share what happened, what we've done about it, and how we're working to improve the reliability of our podcast publishing systems.

What happened?

When a podcast creator publishes a new episode, the audio and video content goes through a series of processing steps before it becomes available to Spotify users. These steps include transcoding (converting media into the formats our apps need) and content analysis.

On June 24, our video transcoding infrastructure reached maximum capacity. This created a backlog that delayed the publication of video podcast episodes for several hours. Creators reported that their episodes were not appearing on Spotify as expected. This image shows the build-up and subsequent emptying of the medium-priority (used for new episodes — shown in blue) and low-priority (used for updates to older episodes — shown in yellow) queues.

What caused it?

On June 24, our video transcoding systems reached maximum capacity. A queue built up and video podcast episodes that would normally be published within minutes were delayed for hours. Creators reported that their episodes were not appearing on Spotify, in some cases this led to creators re-uploading their content which then also contributed to the growing queues.

Five factors converged to create this situation:

1. Our transcoding infrastructure was running with insufficient headroom to handle large spikes of content delivery. During typical periods of content submission our transcoding systems were able to scale and support both low-priority transcoding as well as the high-priority publication of new content. However, there wasn’t sufficient headroom to scale and support large spikes caused by the bulk delivery of new content.
2. A scheduled batch processing job was running. On occasion, we need to re-process existing episodes to be compatible with changes or additions to Spotify’s playback systems. During the June 24 disruption, a routine batch job processing existing content was consuming additional capacity alongside the regular processing for new episodes. While this job appeared fine earlier in the day, it became problematic when combined with increased content submissions.
3. Recent improvements increased per-item processing cost. We had recently made changes to our video transcoding processes in order to provide better quality at lower bitrates for our users. However, this increased the time and processing power needed for each episode, introducing further delays and demand on capacity.
4. Prioritization system malfunction. While the overall system is designed to consider the priority of traffic, this functionality failed in a specific portion of the system, effectively treating batch and backfill operations as equal to new submissions. As a consequence, real-time episode publication was needlessly held back by low-priority reingestion of older episodes and back-catalog content.
5. A software bug was underutilizing available compute resources. Following a recent infrastructure migration to more powerful hardware, a bug in our resource scheduling was causing our systems to underuse the available processing capacity, reducing our throughput by about 10%.

When we identified the issue, we stopped the batch job, deployed a fix for the resource scheduling bug, and added additional processing capacity overnight. By the following morning, all backlogs had cleared and publishing was operating normally. We subsequently added further capacity to provide the headroom that had been missing.

Timeline (UTC)

• 13:30 — Early alerts fire in our internal monitoring. Not immediately recognized as a broader capacity issue.
• 15:00 — Video podcast delivery spike pushes transcoding close to maximum capacity.
• 16:35 — Batch processing job stopped to free capacity.
• 17:34 — Automated alerts confirm queue backlog exceeding thresholds. Incident response begins.
• 19:00 — Creator reports of episodes not appearing on Spotify.
• 20:49 — Software fix deployed to improve resource utilization.
• 00:14 (Jun 25) — Additional processing cluster brought online.
• 01:02 — All queues cleared.
• 07:30 — Full confirmation: all publishing pipelines operating normally.

Where do we go from here?

We have already taken several steps to address this specific incident:

• Increased our transcoding capacity by approximately 67%, providing significantly more headroom for traffic spikes and batch operations.
• Fixed the resource scheduling bug that was leaving under-utilized compute capacity.
• Improved our monitoring to alert earlier when capacity is approaching limits.

Beyond this specific incident, we are investing in broader improvements to the reliability of our podcast publishing pipeline. We've formed a dedicated cross-team effort focused on:

• Building better capacity planning that accounts for not just steady-state traffic, but also burst capacity and incident recovery.
• Improving prioritization across our publishing systems so that real-time content from creators is always processed ahead of background operations.
• Extending rate limiting and backpressure mechanisms throughout the pipeline to handle unexpected load gracefully.
• Improving our processes and technical capabilities so creators get notified as soon as possible when things aren’t working.

We take reliability seriously. When creators publish content, they expect it to be available to their audience when they want it to be, and so do we. We will continue to invest in the resilience of these systems.