Why One Developer Chose Pull-Based Monitoring Over an Event Bus for His Agent Fleet

A solo developer running a personal fleet of agent CLIs, cron jobs, and third-party MCP servers on a single machine wanted a unified inbox to surface items needing human attention. He initially considered an event bus architecture but rejected it because it requires every component — including third-party tools he cannot modify — to actively emit events, creating silent blind spots. Instead, he built a pull-based system that reads on-disk state such as file modification times, process liveness, and health checks, requiring no instrumentation from individual components. This approach is self-healing because it reflects reality even when a component crashes before reporting, since evidence like stale files or absent processes is observable regardless. His conclusion is that for small, high-churn fleets with components outside the developer's control, polling on-disk state is more reliable than depending on producers to push events.