A mature platform reveals its operational state to its customers. An immature one hides it behind a status page that says "all systems operational" when the reality is more nuanced.
We treat observability as a product decision. The reasoning is straightforward: our customers — managed service providers operating a book of tenants — cannot do their job without visibility into ours. If we produce a great detection engine but do not expose its health, we have produced a black box that MSPs will eventually distrust and replace.
What landed in v1.2.1
A single admin URL — Platform Operations Overview — aggregates detector health, verdict volume, cross-feature rule fire rate, DLP incident counts, isolation session counts, and a few dozen other metrics. It auto-refreshes every thirty seconds. Per-tenant health is visible at a glance. The page is intentionally dense because the audience is SOC engineers, not executives.
Seven default observability dashboards ship alongside, covering email security end-to-end, pre-scan hold, journal ingest, browser isolation, DLP, SIEM export, and cross-feature rules. Each dashboard ships with a documented set of questions it answers and a set of alerts it pairs with.
A sidecar health widget joins the existing SOC dashboard. It shows per-tenant circuit-breaker state, last trip time, and 24-hour trip count. This is the widget an MSP's on-call reaches for first when an alert pages.
Metrics are a feature. If a customer cannot see how the platform is performing inside their tenant, the performance claim is unverifiable. Verifiability is not a nice-to-have at enterprise scale. It is the difference between a platform and a promise.
What we did not ship
A prettier status page. Public status pages are marketing artefacts, not operational surfaces. The customers who care about platform state have access to the admin Operations Overview and the dashboards. The public page tracks known incidents; it is not where an SRE starts a triage.
A configurable dashboard builder. Building dashboards is a specialist skill, and most customers neither want nor benefit from a drag-and-drop editor. We ship opinionated defaults that answer the questions SOC teams actually ask.
The engineering culture behind it
An observability surface at this depth is not a one-sprint feature. It is a consequence of a decision made three years ago to structure the platform so every meaningful component emits metrics, traces, and structured events by default. Retrofitting observability is an order of magnitude more expensive than building to it.
Every new service now ships with a dashboard, an alerting runbook, and a capacity plan on day one. A service without those three artefacts does not pass code review. The overhead is real. The payoff is that every release is inspectable from the moment it lands.
Visibility into a platform's operational state is the difference between trust and hope. v1.2.1 is our statement that customers should be able to see everything we see. If a metric matters to our SRE team, it matters to yours too.