How LLM Radar works

1 · Ingestion

A Cron Trigger runs the Worker's scheduled() handler every 30 minutes. It calls every source adapter at once with Promise.all, each with an 8-second timeout, so one slow site can't hold up the rest.

2 · Processing

• Parsing. Workers have no DOMParser, so RSS and Atom go through a ~60-line regex parser that handles CDATA, entities and both link styles. JSON APIs are mapped directly.
• Normalising. Every adapter returns the same shape — { title, link, date, meta } — so the page renders all sources the same way.
• Release filtering. Release candidates, betas and nightlies are dropped; the remaining versions are sorted numerically, so 1.13.1 beats 1.12.7 whatever order the feed lists them.
• Failure handling. Sources are isolated. If one fails, its previous copy is kept and marked stale instead of blanking the card. If KV is empty the first request refreshes inline; if the data is over 2 hours old (cron paused), a request triggers a background refresh.
• Not yet built: cross-source dedupe and ranking. Items are shown per source, newest first.

3 · Storage

• Workers KV — used. The whole snapshot is one JSON value. There is one writer (the cron job) and many readers, and data that changes every 30 minutes doesn't need strong consistency, which is what KV is built for. 48 writes a day, well under the free tier's 1,000.
• D1 — not used yet. Nothing needs querying today. It becomes the right tool once the radar keeps history: dedupe across runs, trends, "new since your last visit".
• R2 — not used. There are no files or blobs to store.

4 · Serving

• Rendering. HTML is built from template strings in the Worker. The page is a single response with inline CSS and about 2 KB of JavaScript.
• Caching. KV reads use a 5-minute edge cache (cacheTtl: 300); browsers cache the page for 60 seconds.
• Latency. p50 ≈ [p50] ms (from Workers Observability).

5 · Cost

Runs for about [$X]/month on Cloudflare's [free / paid] plan.