The self-hosted versus SaaS debate for monitoring usually turns into a cost argument that gets the numbers wrong in both directions. There is a more decisive consideration.
The failure domain problem
Monitoring exists to tell you when your infrastructure is broken. If it runs on the same infrastructure, it is unavailable in precisely the circumstances you built it for. Your monitoring host is in the same datacentre that just had a network problem; your self-hosted monitoring runs in the cluster that just lost its control plane. SaaS monitoring is, by construction, outside your failure domain. That is its single strongest argument and it has nothing to do with features.
The honest cost comparison
The full picture for self-hosting includes infrastructure, days of setup, ongoing maintenance, the on-call burden of the monitoring system itself, and the incident cost when it fails at the wrong moment. That last item dominates and nobody budgets it: storage filling up on your monitoring host at 2am is a compound failure.
When self-hosting genuinely makes sense
Regulatory data residency requirements no vendor satisfies. Air-gapped networks. Scale where SaaS pricing becomes genuinely prohibitive — much further out than people assume. You already have the platform and expertise. Deep customisation that genuinely matters.
When SaaS makes sense
Most of the time, and particularly for availability monitoring. Being outside your failure domain is a structural property you cannot easily replicate, and the operational attention you would spend running monitoring is attention not spent on your product.
The hybrid that works
Metrics, logs and traces self-hosted or in a data platform you control. Availability monitoring and alerting on SaaS — low volume, and it must work when everything else does not.
The uncomfortable summary
If you have a hard constraint, self-host and do it properly, in a separate failure domain, with someone genuinely responsible for it. If you do not, the honest question is whether running one more production system is the best use of your team's finite operational attention. For most small teams, it is not.
