Managed Observability

Every quarter someone at Harborline asks the reasonable question: why does Mara spend days upgrading Loki and forecasting obs-01's disk when Datadog sells all of this as a product? The honest answer is not a winner — it is an exchange rate. Self-hosting pays in engineering time; SaaS pays in invoices and lock-in; and which side of the trade is right depends on team size, data volume, and how much of the stack's operation is differentiating work versus toil.

This topic arms the quarterly conversation with structure instead of vibes: what managed platforms actually sell, how the three market tiers price it, where the costs of each side hide, and a framework for re-running the decision as the numbers change — because they will.

What Managed Buys

The product is operations, not features. Someone else runs the ingest, scales the storage, applies the upgrades, and carries the pager for the observability stack itself. Chapter 12 raised the meta-problem — who watches the watcher, who responds when obs-01 fills at 02:00 — and a managed platform converts that rota into a line item. Everything else on the marketing page is secondary to this trade.

The Integrated Platforms

Datadog, New Relic, and Dynatrace sell one agent, every signal, and cross-signal correlation that works on day one — the metric-to-trace-to-log pivot Harborline hand-built across Chapters 6–8, delivered as a default. For a team with no observability engineering to spare, that day-one coherence is the entire pitch, and it is a real one.

The pricing models are where the three costs from Chapter 1 come back with an invoice attached. The platforms combine per-host infrastructure fees, per-GB log ingest, and per-ingest or per-user charges in vendor-specific mixes — which means the bill scales with exactly the quantities this book taught you to control: cardinality, sampling, retention. The line with teeth is custom metrics, billed by distinct series: one high-cardinality label on a harborline_* histogram moves the meter the same way it moved Prometheus's memory in Chapter 3, except now the consequence is denominated in currency.

Hosted Open Source

Grafana Cloud runs the same stack this book teaches — Mimir for Prometheus metrics, Loki for logs, Tempo for traces, Pyroscope for profiles — priced on usage: active series, GB of logs ingested, trace volume. Every PromQL query, dashboard JSON, and alert rule from Chapters 4–10 transfers unchanged, which makes hosted OSS the lowest-friction exit from self-hosting and, symmetrically, the lowest-friction return if the bill outgrows the convenience. For a team already fluent in the OSS stack, this tier is the default candidate.

Cloud-Native Monitoring

AWS CloudWatch and Google Cloud Monitoring hold a different position: already there, already collecting, and genuinely fine for cloud-resource telemetry — instance CPU, load-balancer 5xx counts, managed-database metrics arrive with zero setup. Their weakness is everything above the infrastructure: cross-signal correlation, application-level depth, anything multi-cloud. The trace-to-log jump Harborline built in Chapter 8 is exactly what they struggle to reproduce, so the sane pattern is both-and — native monitoring for the cloud resources, a real observability stack for the application.

The Real Cost of Each Side

Self-hosting's price never appears on an invoice, which is why it wins dishonest comparisons. It is Mara's hours: upgrades, disk forecasting, scaling Loki when ingest doubles, being the on-call for the on-call system — a real fraction of an engineer, every month, forever. Any spreadsheet that compares a SaaS quote against zero has already reached its conclusion by omission.

SaaS's price is the bill that grows with traffic whether or not anyone looks at the data, egress fees for shipping telemetry out of the cloud, and lock-in through proprietary agents and query languages — the exit cost of a platform whose agent is woven through every service is re-instrumentation, not repointing. The hedge is architectural: instrument with OpenTelemetry regardless of backend, and the data plane stays portable while the storage and query layer stays negotiable.

A Decision Framework

At Harborline's scale — 5 services, 2 hosts, one engineer who cares — either answer works: self-hosting is a hobby with benefits, and a SaaS bill for this volume is small. The calculus shifts when either axis grows 10×. Choose SaaS when engineering time is the scarce resource; choose self-hosted or hosted-OSS when data volume makes usage-based pricing the scarce resource; and re-run the numbers yearly, because ingest grows, team size changes, and vendor pricing moves. The failure is not picking the wrong side — it is treating either answer as permanent.

Small team, engineering time is the scarce resource→Integrated SaaS

Already fluent in the OSS stack, want the pager gone→Grafana Cloud (hosted OSS)

Data volume makes usage-based pricing the pain→Self-hosted

Just cloud-resource telemetry, already collecting→Cloud-native monitoring