--- generated_by: "scripts/seo_markdown_for_agents.py" title: "Podcast Health Checker — Is This Show Still Active?" description: "Check whether a podcast is still publishing: last episode date, days since, cadence, and an active, slowing, or dormant verdict. Free, no sign-up." source_url: "https://thepodcastapp.dev/tools/podcast-health-checker" canonical_url: "https://thepodcastapp.dev/tools/podcast-health-checker" markdown_url: "https://thepodcastapp.dev/tools/podcast-health-checker.md" language: "en" image: "https://thepodcastapp.dev/hero-home-social.jpg" robots: "index,follow,max-image-preview:large" content_signal: "ai-input=yes, search=yes, ai-train=no" --- # Podcast Health Checker — Is This Show Still Active? # Is This Podcast Still Publishing? Type a show name or paste an RSS feed URL. You get the exact date of the last episode, how long ago that was, the publishing cadence, and a plain verdict: active, slowing, or dormant. Two to eighty characters for a show name, or any public http(s) feed URL. Nothing is stored against you. Up and Vanished Serial Reply All A feed URL ## What "active", "slowing", and "dormant" actually mean The verdict is a single arithmetic comparison, not an opinion. We take the most recent publish date we can trust, measure the number of whole days between that date and now, and bucket the result. Under 90 days is **active** . From 90 up to and including 365 days is **slowing** . Over 365 days is **dormant** . When no publish date can be trusted at all, the answer is **unknown** rather than a guess. Those boundaries are deliberately generous: a quarterly show that publishes every 90 days should never be called dead, and a show that skips a summer should not be either. Getting the date right is the hard part, and it is where naive "is this podcast dead" checks go wrong. The obvious approach — download the RSS feed, read the newest `pubDate` , done — fails in two common ways. Large shows publish feeds several megabytes long, so any fetch with a byte cap reads only a prefix; and a meaningful minority of feeds are ordered oldest-first, which puts the newest episode at the very end of the file, exactly the part a capped read never sees. Combine the two and you confidently declare a thriving show dead. Our own earlier implementation did precisely that: it reported *Up and Vanished* as silent since 2017 when Apple's catalogue said 2026-05-05, and *JapanesePod101* as silent since 2022 when Apple said 2026-07-23. So the primary source here is Apple's public iTunes Search API, which returns a `releaseDate` for every show in the Apple Podcasts catalogue — a value Apple maintains from its own ingestion pipeline rather than from a partial read of the file. The RSS feed is a secondary source with one asymmetric power: it can only move the date *forward* . If the feed proves the show is fresher than Apple's index, the feed wins. If the feed merely fails to show recent episodes, it is ignored. That rule is what makes a false dormancy verdict structurally hard to produce, and it is why a result can legitimately say "feed unreadable" and still give you a confident, recent date. Cadence is measured separately and needs the feed, because Apple exposes only the newest release date, not a history. We take the eleven most recent dated items, compute the gap between each consecutive pair, and report the *median* gap in days. Median rather than mean, because a single re-published back-catalogue episode or a bonus trailer dropped between two regular releases would otherwise skew an average badly. If fewer than two items carry a parseable date, cadence comes back unavailable — an honest blank instead of a fabricated number. Episode count follows the same preference order: Apple's `trackCount` when the show is in the catalogue, otherwise the number of items we could read in the feed. The second figure is a floor, not a total, because the read is byte-capped. Every result also carries the issues we hit while gathering it — feed blocked, feed unparseable, feed truncated, no publish date anywhere — so you can see which parts of the answer are solid and which are inference. ## Podcast directories keep dead shows on the shelf Nothing in the podcast ecosystem removes a show when it stops. There is no expiry field in RSS, no "this show has ended" flag that directories agree on, and no incentive for a catalogue to hide a title that still draws searches. A show that published its last episode in 2018 sits in search results, in genre charts, and in "best of" lists indexed years ago, looking exactly like a show that published this morning. The listener finds out only after subscribing and waiting. This matters more than it sounds, because recommendation lists rot silently. When we ran a freshness sweep over our own curated recommendation corpus in August 2026, 201 of 1,507 shows — roughly one in eight — had not published in over a year, and a handful had been quiet since 2018. Those were hand-picked shows on pages we maintain. Any list of comparable age, anywhere, is carrying a similar proportion, and neither the list nor the directory will tell you which entries they are. The people who need this check most are the ones making a commitment: someone deciding whether to start a 200-episode back catalogue, a journalist citing a show as ongoing, a podcaster researching whether a rival slot is genuinely vacant, an advertiser checking that an inventory list still describes reality, or anyone building a recommendation page and wanting to avoid shipping a dead link with a live description. A dormant verdict does not tell you the show is bad. It tells you the thing you cannot see from a directory listing: whether anyone is still making it. It cuts the other way for publishers too. A show that reads as dormant when it is not has a distribution problem worth finding — usually a feed redirect stranded after a hosting migration, or malformed `pubDate` values that no directory can parse. Both are invisible from inside your own dashboard, where the episode obviously exists. They are only visible from the outside, which is the view this tool gives you. ## Sources and further reading - [Apple Search API documentation](https://performance-partners.apple.com/search-api) Apple's public iTunes Search and Lookup API — the source of the `releaseDate` , `trackCount` , artwork, and feed URL this tool treats as authoritative for shows in the Apple Podcasts catalogue. - [Apple Podcasts for Creators — RSS feed requirements](https://podcasters.apple.com/support/823-podcast-requirements) The rules a feed must satisfy to be ingested, including RFC 2822 date formatting and per-episode GUID requirements — the two things most often responsible for a live show reading as dormant. - [RSS 2.0 Specification (RSS Advisory Board)](https://www.rssboard.org/rss-specification) The authoritative spec for the `pubDate` element this check depends on, and for the channel and item structure the feed reader parses. - [RFC 2822 §3.3 — Date and Time Specification](https://datatracker.ietf.org/doc/html/rfc2822#section-3.3) The exact date format RSS `pubDate` values must follow. Dates that deviate from it are the most common reason a feed's newest episodes are unreadable to directories and to this tool. - [Podcast Index](https://podcastindex.org/) Open, independent index of podcast feeds with a free API — a useful second opinion when Apple's catalogue and a show's own feed disagree about which URL is current. - [Podcast Standards Project](https://podstandards.org/) The coalition behind the Podcasting 2.0 namespace, including tags that make a show's status and funding explicit in the feed rather than inferred from silence. - [Podnews](https://podnews.net/) Daily podcast-industry news of record, including regular reporting on show cancellations, hiatuses, and network shutdowns that explain a dormant verdict. - [Edison Research](https://www.edisonresearch.com/) Publisher of the Infinite Dial and Share of Ear studies — the standard reference for how many shows are actively published versus merely listed. - [W3C Feed Validation Service](https://validator.w3.org/feed/) Free syntax check for RSS and Atom feeds — the first thing to run if your own show reports as dormant but you know you published recently. ## Frequently asked questions ### What does "dormant" mean on this page? A show is dormant when its most recent episode is more than **365 days** old. Between **90 and 365 days** it is labelled slowing, and under **90 days** it is active. Those exact thresholds are applied on the server for every check, so two people checking the same show at the same time get the same verdict. A quarterly show publishing roughly every 90 days therefore reads as active or slowing, never dormant. ### Where does the last episode date come from? Primarily from [Apple's public iTunes Search API](https://performance-partners.apple.com/search-api) , which returns a `releaseDate` for every show in the Apple Podcasts catalogue. That date is treated as authoritative. The show's own RSS feed is a secondary source and can only move the date *forward* : if the feed is fresher than Apple's index we use the feed, but a feed we could only read part of can never drag a show into false dormancy. ### Why does it say the feed could not be read but still shows a date? That combination is normal and the result is still usable. Many hosts block server-side fetches, rate-limit unknown clients, or sit behind a CDN challenge. When that happens Apple still answers, so you keep the last episode date and the activity verdict, and only lose the cadence measurement — which needs the feed's list of items. ### How is publishing cadence calculated? From the **median gap between the eleven most recent dated items** in the feed. Median rather than average, so a single re-published back-catalogue episode or a stray trailer cannot distort it. If fewer than two items carry a readable date, cadence is reported as unavailable rather than guessed. ### My show published last week but shows as dormant. What happened? Three usual causes. Apple's index can lag a brand-new episode by a day or two. A feed redirect left over from a hosting migration can leave Apple pointed at an abandoned URL that genuinely has not updated. Or the `pubDate` values on your newest items are malformed, so nothing dated is readable. Check the feed URL Apple has on file for you first — that is the feed this tool follows. ### Does dormant mean the show is cancelled? No. Dormant is a measurement, not a judgement. Limited series that ended on purpose, seasonal shows with long off-seasons, and shows on indefinite hiatus all read as dormant, and plenty of them come back. The tool reports the gap; deciding what it means is up to you. ### Can I check a private, paywalled, or password-protected feed? No. The check runs from our server, so the feed has to be publicly reachable over `http` or `https` . A private feed comes back as unreadable. If the show also has a public Apple Podcasts listing, you will still get the last episode date from there. ### How common are dormant podcasts, really? Common enough that it is worth checking before you recommend a show. In an **August 2026** sweep of our own curated recommendation corpus, **201 of 1,507 shows — about 13%** — had not published in over a year, and a handful had been silent since 2018. That freshness audit is the engine this public tool exposes. ### How fresh is the result, and is it cached? Each show's result is cached on our server for **30 minutes** , and the response carries an `X-Cache` header of `HIT` or `MISS` so you can tell which you got. The *checked* timestamp shown with the result is the moment the underlying data was gathered, not the moment you loaded the page. ### Can I check by RSS feed URL instead of by name? Yes. Paste a full `https` feed URL, or even a bare host and path such as `feeds.example.com/show.xml` — `https` is assumed. URL mode skips name matching entirely, which is the reliable way to check a show with a common title, or one that is not listed in Apple Podcasts at all. ### What should I do if my own show shows as dormant? If you really have stopped, say so in the feed: a short hiatus episode or an updated show description tells listeners far more than silence. If you have not stopped, treat it as a distribution bug. Verify the feed URL registered with Apple, confirm your newest items carry valid RFC 2822 `pubDate` values, and run the feed through the [RSS validator](https://thepodcastapp.dev/tools/rss-validator) before republishing. ### Why is the episode count different from what my podcast app shows? The count prefers Apple's `trackCount` . Apple counts what is in its catalogue, which can exclude trailers, bonus items served from a private feed, or episodes pulled from the public feed but still cached in a listener's app. When Apple has no count we fall back to the number of items we could read in the feed, and that read is byte-capped — so on very large feeds it is a floor, not a total. ### Does this work for YouTube-only or video-first shows? Only if the show also has a public RSS feed or an Apple Podcasts listing. A show distributed solely on YouTube has neither, so it comes back as not found. That is a limit of the available data, not a verdict on the show. ### Is my search query stored? Search terms and feed URLs are used to run the check and are cached briefly on the server so repeat lookups stay fast. Nothing is stored against you, there is no account or sign-up, and the shareable result link you can copy contains only the query you typed. ## You might also like ### RSS Feed Validator Check a feed against Apple, Spotify, and RSS 2.0 rules — the next step if a show you publish reports as dormant. ### Cover Art Checker Check podcast artwork against Apple and Spotify size, format, and quality requirements. ### OPML Viewer & Editor View, search, and edit your subscriptions — useful for spotting shows you follow that stopped publishing. ### Podcast Launch Checklist Work through a practical launch checklist for equipment, branding, hosting, and distribution. ## Follow the live ones in The Podcast App Free on iPhone and Android. Subscribe, download, and pick up where you left off across devices. ## Structured Data ```json { "@context": "https://schema.org", "@type": "WebApplication", "applicationCategory": "UtilitiesApplication", "description": "Check whether a podcast is still publishing: last episode date, days since, publishing cadence, and an active, slowing, or dormant verdict.", "name": "Podcast Health Checker", "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }, "operatingSystem": "Any", "publisher": { "@type": "Organization", "name": "The Podcast App", "url": "https://thepodcastapp.dev" }, "url": "https://thepodcastapp.dev/tools/podcast-health-checker" } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://thepodcastapp.dev/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://thepodcastapp.dev/tools", "name": "Podcaster Tools", "position": 2 }, { "@type": "ListItem", "name": "Podcast Health Checker", "position": 3 } ] } ``` ```json { "@context": "https://schema.org", "@type": "WebPage", "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".page-title", ".page-subtitle", "h1", ".faq-trigger" ] }, "url": "https://thepodcastapp.dev/tools/podcast-health-checker" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "A show is dormant when its most recent episode is more than 365 days old. Between 90 and 365 days it is labelled slowing, and under 90 days it is active. Those exact thresholds are applied on the server for every check, so two people checking the same show at the same time get the same verdict. A quarterly show publishing roughly every 90 days therefore reads as active or slowing, never dormant." }, "name": "What does \"dormant\" mean on this page?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Primarily from Apple's public iTunes Search API, which returns a releaseDate for every show in the Apple Podcasts catalogue. That date is treated as authoritative. The show's own RSS feed is a secondary source and can only move the date forward: if the feed is fresher than Apple's index we use the feed, but a feed we could only read part of can never drag a show into false dormancy." }, "name": "Where does the last episode date come from?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "That combination is normal and the result is still usable. Many hosts block server-side fetches, rate-limit unknown clients, or sit behind a CDN challenge. When that happens Apple still answers, so you keep the last episode date and the activity verdict and only lose the cadence measurement, which needs the feed's list of items." }, "name": "Why does it say the feed could not be read but still shows a date?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "From the median gap between the eleven most recent dated items in the feed. Median rather than average, so a single re-published back-catalogue episode or a stray trailer cannot distort it. If fewer than two items carry a readable date, cadence is reported as unavailable rather than guessed." }, "name": "How is publishing cadence calculated?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Three usual causes. Apple's index can lag a brand-new episode by a day or two. A feed redirect after a hosting migration can leave Apple pointed at an abandoned URL that genuinely has not updated. Or the pubDate values on your newest items are malformed, so nothing dated is readable. Check the feed URL Apple has on file for you first, because that is the feed this tool follows." }, "name": "My show published last week but shows as dormant. What happened?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Dormant is a measurement, not a judgement. Limited series that ended on purpose, seasonal shows with long off-seasons, and shows on indefinite hiatus all read as dormant, and plenty of them come back. The tool reports the gap; deciding what it means is up to you." }, "name": "Does dormant mean the show is cancelled?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. The check runs from our server, so the feed has to be publicly reachable over http or https. A private feed comes back as unreadable. If the show also has a public Apple Podcasts listing you will still get the last episode date from there." }, "name": "Can I check a private, paywalled, or password-protected feed?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Common enough that it is worth checking before you recommend a show. In an August 2026 sweep of our own curated recommendation corpus, 201 of 1,507 shows (about 13%) had not published in over a year, and a handful had been silent since 2018. That freshness audit is the engine this public tool exposes." }, "name": "How common are dormant podcasts, really?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Each show's result is cached on our server for 30 minutes, and the response carries an X-Cache header of HIT or MISS so you can tell which you got. The checkedAt timestamp shown with the result is the moment the underlying data was gathered, not the moment you loaded the page." }, "name": "How fresh is the result, and is it cached?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Paste a full https feed URL, or even a bare host and path such as feeds.example.com/show.xml, and https is assumed. URL mode skips name matching entirely, which is the reliable way to check a show with a common title or one that is not listed in Apple Podcasts." }, "name": "Can I check by RSS feed URL instead of by name?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "If you really have stopped, say so in the feed: a short hiatus episode or an updated show description tells listeners far more than silence, and keeps subscribers from unsubscribing. If you have not stopped, treat it as a distribution bug. Verify the feed URL registered with Apple, confirm your newest items carry valid RFC 2822 pubDate values, and run the feed through an RSS validator before republishing." }, "name": "What should I do if my own show shows as dormant?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "The count prefers Apple's trackCount for the show. Apple counts what is in its catalogue, which can exclude trailers, bonus items served from a private feed, or episodes pulled from the public feed but still cached in a listener's app. When Apple has no count we fall back to the number of items we could read in the feed, and that read is byte-capped, so on very large feeds it is a floor rather than a total." }, "name": "Why is the episode count different from what my podcast app shows?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Only if the show also has a public RSS feed or an Apple Podcasts listing. A show distributed solely on YouTube has neither, so it comes back as not found. That is a limit of the available data, not a verdict on the show." }, "name": "Does this work for YouTube-only or video-first shows?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Search terms and feed URLs are used to run the check and are cached briefly on the server so repeat lookups stay fast. Nothing is stored against you, there is no account or sign-up, and the shareable result link you can copy contains only the query you typed." }, "name": "Is my search query stored?" } ] } ```