Caching and limits

The feed is built to be cached hard. Only one small file ever changes.

What is cached, and for how long

File	`cache-control`	Why
The manifest, `feed/index.json`	`public, max-age=60`	It points at the current build, so it is kept fresh.
Everything under `b/{buildId}/`	`public, max-age=31536000, immutable`	A build is written once and never changes, so it can be cached for good.

A new article shows in the feed as soon as the manifest you hold is replaced: within a minute, or at once if you re-read it when a webhook arrives.

Each publish writes a whole new build beside the old one, then points the manifest at it. So:

You never see half a rebuild. A reader part-way through an old build’s pages still gets a complete, consistent list.
Stale reads are safe. A cached page from an older build is still a true record of that moment.
Old builds go away later. They are kept for a while after a new one lands, then removed. Start from the manifest each time and you will never ask for one that is gone.


Articles a page	20 (the manifest’s `pageSize`), newest first
Paging	Pages `1` to `pageCount`, from the manifest
Cross-origin	Any origin may read every file
Key	None
Rate limits	None to plan around. They are static files on Cloudflare’s network.

A static site reads the feed at build time. Rebuild when a webhook arrives.
A server-rendered site can read the feed on each request and let fetch and the network do the caching, or hold the manifest for a minute and the build’s files for as long as it likes.
In the browser, the same caching applies. Rendering articles in the browser alone means search engines and AI assistants may not see them, so prefer the server.

You asked for	`404` means
The manifest	The site ID is wrong, or the site has no feed. A site with nothing live still has a manifest, with `total` 0.
A by-slug file	No live article has that slug.
A page or by-slug file from a build you kept	That build is gone. Read the manifest again.