The choice is presented as build against buy and is usually argued on price. Price is the least stable part of it. What actually differs is which obligations you hold, and the total quantity of obligation is roughly constant.
What each side owns
Run it yourself and you own capacity planning, upgrades, high availability, backups that have actually been restored at least once, and an on-call rotation for the monitoring system itself. That last item is the one nobody costs.
Buy it and you inherit somebody else's pricing model, retention tiers, query language and release schedule. You also inherit their availability, which matters in a specific way discussed below.
What neither arrangement moves is the part that was always the real work: deciding what to collect, what deserves an alert, and what any of it is for. A supplier can operate a database for you. Nobody can outsource knowing which question you are asking.
The monitoring system needs monitoring, and it must not be its own
A self-hosted stack that watches everything including itself will, when it fails, report nothing, and reporting nothing looks like calm. Something outside it has to notice the silence, which means at minimum a small independent check somewhere else, and that check is the first thing cut when a platform team is busy.
Buying shifts this and does not remove it. A supplier's outage during your incident leaves you blind at precisely the moment the tool exists for, and the honest question at procurement is what the plan is for that hour. Usually there is none, which is a defensible position provided it was chosen rather than assumed.
The cost curves have different shapes, not just different heights
Managed pricing is broadly linear in usage: predictable per unit, awkward when usage grows faster than the budget, and it grows exactly when things are going well.
Self-hosted cost is lumpy, because it is mostly people. It looks free until it needs a second person who understands the storage layer, and then it steps. Comparisons that put an infrastructure bill next to a subscription and stop there are comparing one of the two costs.
Two line items are routinely missed. The cost of moving data out of a cloud provider to an external supplier, which is charged by volume and does not appear in either quotation. And the engineering time spent on the monitoring system rather than on the product, which is the largest number in the comparison and appears in no invoice at all.
Where the data sits is sometimes not negotiable
Some organisations cannot send certain data outside a jurisdiction, a sector-specific boundary, or their own network. Where that applies it settles the question before any cost comparison, and it applies far more often to workforce monitoring than to infrastructure telemetry, because that data is about identifiable people.
The reverse consideration deserves saying too. Running a workforce monitoring system on your own hardware moves the breach liability to you. Regulated buyers frequently insist on it for good reasons and acquire an obligation they are less equipped to meet than the supplier was.
Lock-in lives in the definitions, not the data
Exporting historical data is usually possible and usually not the problem. The expensive part is everything written around it: dashboards, alert rules, saved queries, the query language they are written in, and the instrumentation embedded in application code.
The one structural defence is the separation described in the article on telemetry shapes. Instrument with a vendor-neutral standard and the backend becomes a decision that can be revisited. Instrument with a supplier's own library and it becomes a decision that can only be regretted.
Hybrid is the common answer and is rarely stated as a plan
Most organisations that have been doing this a while end up splitting: bulk, high-volume, low-value data kept locally on cheap storage, and the smaller high-value slice sent to a managed service for querying and alerting. Or collection run in-house with storage bought.
This works well and it accumulates by accident, which is the problem. A split that was designed can be reasoned about; a split that grew has two systems, two sets of alert rules, and no one who knows which of them is authoritative during an incident.
Scale is the wrong first question
The usual framing asks at what volume self-hosting becomes cheaper. The more useful question is whether operating a storage system at all is work this organisation should be doing. A team of five without a platform engineer should almost never be running a highly available time-series database, at any price, because the failure of that database will occur during the incident it was bought to help with.
What we cannot verify
Pricing, egress rates and licensing terms are published by suppliers, change frequently and differ by contract; we quote none. Comparisons circulated in this market are usually produced by one of the two sides. The only comparison worth acting on is one built from your own volumes, your own staff costs and your own retention requirement, and it should be rebuilt when any of the three changes.
The short version
- The obligations do not disappear; they change hands and change shape.
- Deciding what to collect and what it is for cannot be outsourced.
- A monitoring system that watches itself reports nothing when it fails.
- Managed cost is linear in usage; self-hosted cost is lumpy because it is people.
- Egress charges and engineering time appear in neither quotation.
- Lock-in lives in dashboards, alert rules and instrumentation, not in the data.