When a Source Stops Updating

Adding sources covers a feed that will not resolve in the first place. This is the other problem: it resolved, it worked, and now it has gone quiet.

Most of the time nothing is broken. Work through it in this order.

First, how often is it even checked?

Your plan sets the cadence:

Plan	Sources refresh every
Free	3 hours
Starter	1 hour
Pro	30 minutes
Max	15 minutes

So on Free, a source that published twenty minutes ago has not been missed — it has not been looked at yet.

Sources are shared between readers, and a shared source is fetched at its fastest subscriber's cadence. If anyone on Max follows the same publication, it is checked every 15 minutes for everyone, including you. This works in your favour and is not something you can arrange deliberately.

Second, is the source actually publishing?

The most common answer, and the easiest to check: open the site. A blog that posts monthly looks identical to a broken feed for four weeks at a time.

The number beside each source in the Feeds tree is how many articles it published in the last seven days — a busyness reading, not a total. A 0 there means the source has been quiet for a week, which is the same thing whether the publisher stopped writing or the fetch stopped working, so it tells you where to look and not what is wrong.

Deliberately, nothing in the reader calls a source broken on the strength of that number. A quiet week is not a fault, and a reader offered a "clean these up" button on that basis unsubscribes from the things they read least often rather than the things that are failing.

What happens when a fetch fails

A failure does not take the source out of rotation. Feedpik backs off and keeps trying, doubling the wait each consecutive failure:

15 minutes → 30 minutes → 1 hour → 2 hours → … capped at 12 hours.

After 10 consecutive failures — roughly two days of trying — it stops scheduling that source. That window is chosen to outlast the things that are genuinely temporary: a rate limit, a certificate renewal, a publisher's bad afternoon. What it will not do is keep knocking for weeks on a domain that is gone.

A single success resets the counter completely.

None of this is shown to you. The reader has no per-source status, so a feed being retried and a feed that has been given up on look identical from the outside — both simply stop producing articles. The seven-day count going to 0 is the only signal, and it cannot tell you which.

That is a gap on our side rather than something for you to work around, and it is why checking the publisher's own site comes first below: it is the one thing that separates the source went quiet from the fetch went wrong, and right now you can find out faster than we can tell you.

Why a fetch fails

In rough order of how often we see it:

Rate limiting. The publisher returned 429 because their feed is popular. Resolves itself; the backoff is designed for exactly this.

Bot protection. Some sites put their feed behind the same challenge as the rest of the page. Nothing at either end is misconfigured — the publisher has decided readers should not fetch it automatically.

The feed moved. Sites reorganise and the old address 404s or redirects somewhere unhelpful. This one does not fix itself.

TLS and connection errors. A lapsed certificate, a host that stopped answering. Usually temporary, occasionally the first sign a publication has shut down.

There is no refresh button, on purpose

Fetching is the schedule's job, and it is not something you should have to think about. A reader with a refresh button is a reader that quietly expects you to press it — and then a source that goes quiet becomes your problem to notice, diagnose and poke, which is the opposite of what a feed reader is for.

So there is nothing to press, on a single source or on all of them, and that is the design rather than a missing piece.

It also would not do what it appears to. A refresh button on a source publishing hourly returns the same articles you already have; on a rate-limited source it asks a publisher who has just said slow down to answer again, which is how a temporary 429 becomes a longer one. The backoff exists because waiting is genuinely the better move, and a button undoing it would mostly be used at exactly the wrong moment.

What to do instead

Nothing, usually. A rate limit or a publisher's bad afternoon clears on its own, generally within hours. The retry schedule is already working on it.

Re-add it at its new address if the feed moved — that is the one failure that never resolves itself. Look for an RSS icon on the site, or try /feed, /rss or /atom.xml after the domain. A direct feed URL always works.

Re-add it if it has been quiet for several days and the site is clearly still publishing. Adding a source fetches it immediately and starts its counters clean, which is what gets a genuinely stuck feed moving again.

Leave it. A source that stopped being scheduled costs you nothing, takes no quota you would otherwise use, and is ten seconds to add back whenever you notice.

If something looks wrong

One source is quiet, everything else is fine — that source. Check the site, then re-add it.

Everything is quiet — not the feeds. Check you are looking at the right persona; sources belong to the persona that was active when you added them. See personas.

A source I just added has no articles — some publishers only put a handful of recent items in the feed, and some publish rarely. Give it a day before deciding.

It updates, but hours after the site does — that is your plan's cadence, and it is the thing upgrading changes most visibly. See plans.

The feed loads fine in my browser but not here — usually bot protection, which is built to tell a browser from a feed reader and is doing its job. Re-adding it will not help. Some publishers offer a second feed address for readers; if not, the site has decided this.

The count says 0 but articles are arriving — the count is a seven-day window over what has been published, so a source whose last post is eight days old reads 0 while still working perfectly.