Archive status

Why this page exists

Every vendor in this market publishes latency figures. None publishes a per-source uptime you can check. That’s not an oversight — scrapers break weekly when a platform changes something, and a number that admits it is uncomfortable to publish.

The uncomfortable version is the useful one. If you’re going to depend on trend data, the question isn’t how fast the API responds. It’s which sources actually collected today.

What the states mean

• collecting — captured within the last 90 minutes.
• delayed — 1.5 to 3 hours. Usually the scheduler: GitHub’s cron is best-effort and slips under load.
• stale — nothing recorded for over 3 hours. Either the collector broke, or the source had nothing to say. This page can’t tell those apart, and says so rather than guessing.
• no data — nothing recorded yet, or the source was reset.

A source can be up and still be wrong

This page reports whether data arrived, not whether it was right. Those are different failures, and the second is harder.

One of these sources spent two hours collecting stories about an e-ink bike computer because a single overly broad search term dominated the results. Every counter looked healthy the whole time. Those windows were deleted rather than kept, because a contaminated baseline poisons every comparison made against it afterwards.

A green row means the pipe is open. It does not mean the water is clean.

An empty source looks exactly like a broken one

Right now one of these sources is marked stale and nothing is wrong with it. Indie SaaS is collected from Hacker News, and Hacker News mostly doesn’t discuss indie SaaS — so the collector runs on schedule, finds nothing, and writes nothing. No row written is indistinguishable from no run at all.

We could hide that by recording empty runs and painting the row green. It would look better and mean less. A source that reliably returns nothing is a real problem — just ours, not yours — and the honest fix is another source, not a friendlier colour.