Check freshness, not reachability. They are different questions and only the first one is easy, which is why most health checks answer the second one and stop.
What that looked like for me
I built a monitor that reads 45 sources. Its health check fetched every one, confirmed the response parsed, counted items, and printed a line per source. Forty-three came back ok.
Then I looked at the dates.
| Source | Items in feed | Newest item | Silent for |
|---|---|---|---|
| Chip Huyen | 10 | 2025-01-16 | 612 days |
| Zendesk | 100 | 2024-03-20 | ~550 days |
| Airtable | 15 | 2025-09-29 | 356 days |
| Dan Shipper, Chain of Thought | 50 | 2026-07-10 | 72 days |
Every one returned HTTP 200. Every one parsed as valid XML. Every one held a healthy number of well-formed items with titles, links, and dates.
All four were dead, and the monitor called them healthy, because I had written the check that was easy to write.
The fix
Record the newest item date from each source on every run. Compare it to the run date. Threshold the gap against how often that source normally publishes.
Two thresholds in my case: 35 days for a source that normally publishes weekly, 120 days for one that publishes rarely. Flagged sources come back with a recommendation to demote or drop.
The numbers are not the point and I would not defend them. The point is that the default threshold is infinity and anything finite beats it.
The state the fix really adds
What that check does underneath is split one state into two.
Most pipelines collapse "this source is alive and had nothing to say this week" and "this source stopped existing" into the same empty result set. The first is information. The second is a defect. A system that cannot tell them apart will report the defect as information on every run, confidently, in a well-formatted table, indefinitely.
There is a second-order version worth building in. When the monitor flagged a newsletter at 72 days, the obvious read was that the author had gone quiet. The likelier read, given that the publication ships several times a week, was that I had the wrong feed URL. Those need opposite fixes, so the flag has to say which one it suspects or half the corrections will be wrong.
The one thing to do this week: take one agent you trust and find the date on the last real thing that came through its freshest input. Not whether the pipe is open. The date. If that takes longer than a minute, you have a green light rather than monitoring.