Why Your Podcast Might Not Be Playing

Straight answer: nine times out of ten, a podcast that won't play isn't a platform problem, it's a file, feed, or caching problem you created without realising it. The audio encoding, the RSS feed, or a change you made after publishing is almost always the culprit, not Spotify or Apple having a bad day. Fix those three things in order and most playback issues clear up within 48 hours.

Start by ruling out the boring stuff

Before you touch your hosting settings, check three things that take two minutes combined. Is your phone or app connected to the internet, not just showing bars. Have you updated the podcast app in the last month, because Apple Podcasts and Spotify both push updates that occasionally break older cached episodes until you refresh. And has the episode finished processing on your hosting platform, because Libsyn, Buzzsprout and Transistor all show a "processing" state for a few minutes after upload where the file exists but isn't fully readable yet.

If none of that explains it, the problem is almost certainly one of three things: the audio file itself, your RSS feed, or caching on the listener's end. Let's go through each one, because they need different fixes.

What happened to my own show

I'll tell you exactly where this bit me. I'd recorded an interview episode, and about eleven minutes in there was a coughing fit from my guest that needed cutting. Simple edit, five minutes of work in the editing software, re-exported the MP3, and uploaded it to the same file URL my hosting platform had already given the original version. Same episode title, same show notes, just a cleaner file sitting where the old one used to be.

For three days, some listeners heard the old version with the cough still in it, some got an episode that played the first four minutes and then went silent, and a couple emailed me saying the episode "wouldn't load at all" on Apple Podcasts. Nothing was wrong with my hosting account. What had happened is that Apple's servers had already crawled and cached the original file, including its exact file size in bytes, which gets written into the RSS feed's enclosure tag. When I swapped the file for a slightly smaller one without changing the URL or the GUID, Apple's cached version of the feed still expected the old byte count. Some devices played the cached copy, some tried to stream the new file against old metadata and choked on the mismatch, and Apple's own recrawl of my feed took just over three days to catch up and serve the corrected file consistently. Replacing a live audio file at the same URL is one of the fastest ways to break playback for a chunk of your audience, and almost nobody warns new podcasters about it.

The file itself: bitrate, format and size

Podcast apps are far less forgiving of odd audio encoding than YouTube or a website video player. The safest, most widely compatible format is still a constant bitrate MP3, not variable bitrate, because VBR files can cause scrubbing and duration glitches in Apple Podcasts specifically, where the little progress bar shows the wrong length or jumps when you try to skip forward.

• For a solo voice show, 128kbps mono is enough and keeps files small.
• For interviews or anything with music, 192 to 256kbps stereo is the usual range.
• Sample rate should sit at 44.1kHz, not something unusual like 48kHz carried over from video editing software, which some older apps mishandle.
• A 30 minute episode at 128kbps mono should land around 27 to 30MB. If your file is 80MB or more for the same length, you're almost certainly exporting at a bitrate or setting that's overkill and will load slowly on weaker connections.

Large files matter more than people think. A listener on patchy 4G trying to stream a 150MB episode is going to experience buffering that looks exactly like a "won't play" problem but is really just a file that's needlessly bloated.

Your RSS feed is doing more work than you realise

Every podcast app on earth, Apple, Spotify, Overcast, Pocket Casts, reads your RSS feed, not your hosting dashboard. The feed is a piece of XML that lists every episode, its file URL, its file size, its duration, and a unique identifier called a GUID. If that XML has an error in it, even something as small as an unescaped ampersand in your show notes or a stray curly quote pasted in from Word, some apps will fail to parse the whole feed and simply stop showing new episodes, sometimes without any visible error message to you.

This is where I'd push back on the usual advice, which is to blame the podcast app and wait it out. The uncomfortable bit nobody likes admitting is that most "Spotify won't play my show" complaints trace back to something the podcaster did to their own feed: renaming an episode file after publishing, changing hosting providers without setting up a proper redirect, or manually editing show notes in a way that broke the XML. Platforms get blamed constantly for problems that are sitting in your own RSS feed, and checking the feed is a five minute job most people skip because it feels too technical.

Run your feed URL through a free RSS validator (Google "podcast RSS feed validator" and you'll find several, including one built by Apple's own podcast connect tools) before you assume the platform is broken. It will flag malformed XML, missing enclosure tags, and duration mismatches in plain language.

Caching: why it plays fine on your phone but not theirs

Podcast apps cache aggressively to save data and battery. That means when you fix a broken episode, it can look perfect on your own device within seconds because you're often already logged in and the app pulls fresh data more eagerly for the account owner, while a listener's copy of Apple Podcasts might not recheck your feed for hours. Apple in particular can take anywhere from a few hours to 48 hours to fully recrawl a feed after a change, which is exactly why "it's working now" tests on your own phone are unreliable proof that a fix has gone live for your audience.

Spotify behaves a little differently since it ingests feeds and stores episodes on its own infrastructure rather than always streaming live from your host, which is partly why a broken file sometimes shows up on Apple but plays fine on Spotify, or the other way round. They're not reading from the same cached snapshot at the same time.

A step by step check when an episode won't play

1. Play the raw file URL directly in a browser, not through the app. If it doesn't play there, the problem is the file or the host, not the platform.
2. Check the file size in your hosting dashboard against what a browser reports when you download it. A mismatch means the enclosure tag in your feed is out of date.
3. Validate your RSS feed for XML errors, paying attention to any special characters in titles or show notes.
4. Confirm the GUID for the episode hasn't changed since it first went live. If you replaced a file at the same URL, some hosts silently generate a new GUID, which some apps read as a duplicate or brand new episode and get confused by.
5. Wait at least 24 hours after any fix before assuming it hasn't worked, because of caching delays.
6. Test on a second device that isn't logged in as you, ideally on someone else's phone, since your own account often refreshes faster.

What to check before you ever hit publish

Most of this is preventable rather than fixable after the fact. Export at a consistent bitrate every time so you're not troubleshooting a different problem each episode. Never overwrite a live audio file at the same URL once it has gone out, upload it as a new file and update the feed instead. Keep your show notes free of pasted-in curly quotes and special characters from Word or Google Docs, since those are a surprisingly common source of broken feeds. And treat your podcast the same way you'd treat any other piece of content marketing strategy, with a proper publishing checklist, rather than something you upload and hope for the best on.

If you're building a show as part of a wider growth push, this matters more than it looks like it does on the surface. I've worked with founders during their startup growth phase who put real budget into guests and editing, then lost weeks of listener trust because episodes were silently failing to load for a chunk of their audience and nobody noticed until a listener complained on social media. Distribution problems are invisible until someone tells you, which means you have to go looking for them rather than waiting for feedback.

It's also worth repurposing carefully once your feed is stable. Turning an episode into a video for your YouTube channel or a set of quotes for LinkedIn using AI for LinkedIn content only works if the original audio is reliable to begin with, so fix playback first and repurpose second.

Frequently asked questions

Why does my podcast play on Apple Podcasts but not Spotify?

The two platforms don't read your feed at the same time or in the same way. Apple streams closer to live from your RSS feed while Spotify ingests and stores episodes on its own servers, so a recent file change or feed error can show up on one platform hours or days before the other catches up.

Why does my episode show 0:00 or the wrong duration?

This almost always means the duration or file size listed in your RSS feed's enclosure tag doesn't match the actual file, usually because you replaced or re-exported the audio after the feed was first generated without updating those values.

Should I use variable bitrate or constant bitrate for podcast audio?

Constant bitrate. Variable bitrate MP3s are known to cause scrubbing and duration glitches specifically in Apple Podcasts, and the file size savings aren't worth the playback risk for spoken word audio.

How long does it take for a fixed episode to work again for listeners?

Give it at least 24 to 48 hours before assuming a fix hasn't worked. Apple in particular can take that long to fully recrawl and refresh a feed, so testing on your own device minutes after a fix isn't a reliable indicator.