Podcast backlog calculator
40 unplayed episodes of 55 minutes at 1.25 times speed are 1,760 minutes, a little over 29 hours of listening. Enter your queue, the usual episode length and the speed you really use to plan your catch-up. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Episodes
- 40
- Duration
- 55
- Speed
- 1.25
- Minutes
- 1,760
- Hours
- 29.3333333333
A podcast backlog is a listening-time problem, not a catalog lookup. You already know how many unplayed episodes sit in the queue, you already know the typical length of that show, and you already know whether you listen at the original pace or at one-and-a-half or two times speed on a commute. This calculator turns those three numbers into a single wall-clock figure: total listening hours. Multiply the episode count by the average duration in minutes, divide by the playback speed you will actually use, then divide by sixty. A forty-episode news show at fifty-five minutes and one-and-a-quarter speed is a little over twenty-nine hours — more than a full waking day if you tried to clear it in one sitting. Missing, non-finite, or out-of-range episode counts and durations fail the same way and are not billed.
How podcast backlog hours are computed from three numbers
The identity is the same one every podcast player uses internally when it estimates remaining time. Gross runtime in minutes is the episode count multiplied by the average duration of one episode in minutes. Listening time in minutes is that product divided by playback speed.
Hours are listening minutes divided by sixty. Playback speed is a positive multiplier: 1.0 is the original soundtrack, 1.2 and 1.5 are the common Overcast and Pocket Casts settings commuters use to clear a queue faster, and 2.0 halves the clock. A value below 1.0 — slow playback for language study, a restored interview, or a player that stretches speech — lengthens the listen, which is why the field is not clamped to at least one.
Fractional episode counts are accepted because leftover half-episodes, bonus trailers, and two-part finales are real; the arithmetic does not force an integer. Average duration may be any positive finite number of minutes, including the odd forty-seven-and-a-half-minute news magazine that is neither a tidy half-hour nor a tidy hour.
What to enter and how speed changes the time
Errors always name the canonical field so the web form can mark the right control. Zero and negative playback speed fail because a player cannot divide time by a non-positive rate — that is the contract this capability exists to enforce, and those failures are not billed. Zero or negative episode counts and durations fail for the same reason: a backlog with no episodes or a zero-length episode is not a listen.
Magnitudes above the documented ceilings fail so a typo cannot blow the isolate. On success the body includes the echoed inputs, minutes as the listening clock, hours as minutes divided by sixty, and a formula string. A familiar check is forty episodes of fifty-five minutes at speed 1.25, which yields one thousand seven hundred sixty listen minutes and 29.333333333333 hours.
A one-hundred-episode, thirty-minute daily show at double speed is twenty-five hours.
Where a podcast backlog calculator earns its keep
Households planning a commute catch-up need hours so they can decide whether a forty-episode news backlog fits in two weeks of driving or needs a faster speed. Newsletter writers and recap editors building a listening calendar need a deterministic conversion from episode count and average runtime to a wall-clock budget they can pin in a spreadsheet.
Language students who drop a Spanish or Japanese interview show to four-fifths speed need the same formula with a rate below one, not a tool that silently refuses anything other than real time or double time. Club programmers and hospitality teams running a themed listen-along can turn a stack of episodes into a start-to-finish clock without opening a calculator for every title.
Keep all three inputs finite, keep speed strictly positive, pin hours in your tests, and you get a reproducible listening budget for a commute plan, an editorial calendar, a language-lab worksheet, or an edge worker without standing up a podcast directory of your own.
What you can do with it
Catch up on a weekly interview show
Turn a forty-episode, fifty-five-minute backlog at 1.25x into about twenty-nine hours so you know whether two weeks of commuting is enough.
Compare 1x, 1.5x, and 2x playback
Keep the same episode count and average duration, change only speed, and see how many wall-clock hours a faster soundtrack actually saves.
Plan commute and gym listening
Convert a daily news queue into hours you can match against drive time or treadmill sessions without opening a spreadsheet for every show.
FAQ
How do I calculate total listening time for a podcast backlog?
Send three numbers: episodes, duration (average minutes per episode), and speed.
What units is duration in?
Duration is the average episode length in minutes, the unit printed on most podcast info cards. Hours appear only in the result after the listening clock is converted.
What happens if playback speed is zero or negative?
A player cannot divide time by a non-positive rate, and those failures are not billed.
Does this pull my queue from Apple Podcasts or Spotify?
No. You supply the episode count and average duration yourself.
Does it subtract intros and ads?
No. It counts every listed episode at its average length and at one constant speed. If your show has long ads you skip, enter a shorter average length to reflect what you actually hear.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/life/podcasts \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"episodes":40,"duration":55,"speed":1.25}'const res = await fetch("https://api.kit.forhosting.com/life/podcasts", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"episodes": 40,
"duration": 55,
"speed": 1.25
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/life/podcasts",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"episodes": 40,
"duration": 55,
"speed": 1.25
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/life/podcasts", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"episodes":40,"duration":55,"speed":1.25}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"episodes":40,"duration":55,"speed":1.25}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/life/podcasts", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"episodes": 40,
"duration": 55,
"speed": 1.25
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "life.podcasts",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_episodes | 1000000 |
max_duration | 1000000 |
max_speed | 100 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Zero or negative playback speed is rejected as invalid_input, because a player cannot divide time by a non-positive rate. Use the page in your browser at no charge, or call the API at $0.002 per successful request when a catch-up calendar or coaching worksheet needs the identical figure.
How podcast backlog hours are computed from three numbers
The response echoes the cleaned episodes, duration, and speed, then returns minutes as the listening clock, hours as minutes divided by sixty, and a formula string that restates the identity so a user interface can show the rule next to the number. This endpoint does not fetch episode lists from an RSS feed or a directory, does not subtract intro music or ads, and does not apply time zones. It answers one question: if you play every listed episode at a constant speed, how many hours of listening is that backlog.
Input contract, playback speed, response fields, and validation errors
POST a JSON body with three required fields: episodes, the count of unplayed episodes in the backlog; duration, the average runtime of one episode in minutes; and speed, the playback multiplier. Aliases episode_count, n, and count are accepted for episodes; average_duration, avg_duration, episode_duration, and minutes for duration; and playback_speed, playback, and rate for speed. Each field may arrive as a JSON number or as a numeric string; booleans, objects, empty strings, NaN, and Infinity fail with invalid_input. Missing fields are invalid_input and are not billed. Successful API calls use the published $0.002 base price; the free browser path runs the same solve function without consuming prepaid balance.
Technical questions
What does the podcast backlog calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.