Nagios vs Sensu: which is better for modern alerting?

Nagios and Sensu both run health checks against infrastructure, but Sensu's API-first, event-driven pipeline fits fast-changing cloud environments better, while Nagios's simpler polling model still holds up well on stable, mostly-static fleets. Sensu was rewritten from Ruby into Go as Sensu Go in 2019, a change aimed squarely at container-scale deployments.

Where Nagios still holds up

Nagios remains a solid choice where the infrastructure list barely changes and the team already trusts its plugin ecosystem. Its check scheduling is predictable and well documented, and the huge library of Monitoring Plugins-compatible scripts covers most common services out of the box. Teams that don't need an API to manage checks programmatically save themselves Sensu's extra moving parts: a backend, agents, and a message bus to keep running.

Where Sensu pulls ahead

Sensu fits better once infrastructure is provisioned and torn down constantly, since its agents register themselves instead of requiring a config file edit for every new host. The event pipeline also lets teams route different failures to different handlers, like paging only on production namespace alerts, without bolting extra logic onto the core. That flexibility comes at the cost of running more infrastructure than Nagios needs by itself.

Who should pick which?

Ops teams managing a mostly static server fleet, with monitoring already built around Nagios plugins, have little reason to migrate. Platform teams running Kubernetes or autoscaling cloud infrastructure, where hosts appear and disappear daily, tend to get more value from Sensu's registration model and API-driven configuration.