06 · Unified Observability & Monitoring Platform

Milestones of the roadmap items in this theme

As of 2026-10-22 · today

Gantt

#	Milestone	Start	Target	Status	Waits for	Team	Epic	Derived
17 · Telemetry Collection Infrastructure
17.1	Alloy the only collector, deployed at every source	2026-09-01	2026-12-18	in progress	—	SRE · Platform Engineering	—	—
17.2	Every source reporting, or named as an exception	—	2027-07-16	planned	3.1, 17.1	SRE · Platform Engineering	—	waiting 3.1, 17.1
17.3	Pipeline capacity and retention sized against real volume	—	2027-11-19	planned	17.2	SRE · Platform Engineering	—	waiting 17.2
18 · Unified Monitoring Platform
18.1	SLIs and SLOs agreed with service owners, starting from none	—	2027-11-19	planned	17.2	SRE · Platform Engineering	—	waiting 17.2
18.2	Alerts that are actionable and tied to the SLOs	—	2028-03-10	planned	18.1	SRE · Platform Engineering	—	waiting 18.1
18.3	Dashboards as code, not clicked together	—	2028-03-10	planned	14.2, 18.1	SRE · Platform Engineering	—	waiting 14.2, 18.1
19 · ELK & Pinpoint Migration to Grafana LGTM
19.1	Applications instrumented once, with OpenTelemetry	—	2027-09-10	planned	17.1	Application development	—	waiting 17.1
19.2	Old and new side by side, parity verified per service	—	2028-05-19	planned	18.3, 19.1	SRE · Platform Engineering	—	waiting 18.3, 19.1
19.3	Elasticsearch and Pinpoint decommissioned	—	2028-11-17	planned	19.2	SRE · Platform Engineering	—	waiting 19.2

17.1Alloy the only collector, deployed at every source2026-12-18in progress · 1/4

Mimir, Loki and Tempo deployedowner · Charlesarchitecture →
The backends exist. What is left is getting the estate to send to them, which is what the rest of this item is about.
Alloy on VMs via systemd and on Kubernetes via DaemonSetowner · TBD
The agents Alloy supersedes removed, not left running alongsideowner · TBD
Alloy replaces the Prometheus agent, Promtail and the OTel Collector. Leaving one running means two collectors with different label sets, and a metric that disagrees with itself is worse than a metric that is missing.
Tenant identity stamped on every writeowner · TBD
X-Scope-OrgID is what keeps one tenant from reading another and what makes per-tenant cost visible; it has to be stamped at collection, not repaired later.

17.2Every source reporting, or named as an exception2027-07-16planned · 0/4

The hosts 3.1 found missing from Mimir brought in or excluded with a reasonowner · TBD
3.1 produces that list as a by-product of building its baseline; this is where it stops being a data-quality note and becomes closed.
Coverage measured the same way for logs and traces as for metricsowner · TBD
Metrics coverage is visible because something already counts it. Logs and traces have no equivalent until one is built, so their gaps are invisible rather than absent.
Coverage published as a number that can be tracked over timeowner · TBD
A source that reports nothing is treated as a finding, not a defaultowner · TBD
Blind spots are found during incidents, which is the worst time and the worst way to find them.

17.3Pipeline capacity and retention sized against real volume2027-11-19planned · 0/4

Ingest rate measured per signal, not estimatedowner · TBD
WAL buffering verified by actually stopping a backendowner · TBD
A buffer nobody has tested is a claim in a config file. The point of testing it is that a backend outage is exactly when nobody can look at anything.
Retention decided per signal against object-storage costowner · TBDarchitecture →
The multi-IDC Mimir path exercised, not just designedowner · TBDarchitecture →
The design is written down in detail; what is not yet known is how it behaves when a site is unreachable.

18.1SLIs and SLOs agreed with service owners, starting from none2027-11-19planned · 0/4

Which services get an SLO first, chosen by user impact rather than by easeowner · TBD
SLIs defined from what a user experiencesowner · TBD
CPU utilisation is not an SLI. It is easy to measure and it is not what anyone outside the team notices.
Each SLO agreed in writing by its owner, with an error budgetowner · TBD
What happens when the budget is spent, agreed in advanceowner · TBD
An SLO with no agreed consequence is a dashboard. The consequence is the whole mechanism — and it has to be agreed before it is needed, because after a breach the conversation is about blame instead.

18.2Alerts that are actionable and tied to the SLOs2028-03-10planned · 0/4

Existing alerts inventoried, and the ones nobody acts on deletedowner · TBD
An alert that fires and is ignored trains people to ignore alerts, so deleting it improves safety rather than reducing coverage.
Alerts derived from symptoms and SLO burn rate, not from causesowner · TBD
Cause-based alerts fire for conditions users never notice, and stay silent for failures nobody predicted.
Every alert carries a runbook link and a named ownerowner · TBD
Alert volume measured before and afterowner · TBD

18.3Dashboards as code, not clicked together2028-03-10planned · 0/4

Dashboards declared in Git and reconciled by ArgoCDowner · TBD
14.2 makes platform components reconciled rather than applied; dashboards are one of those components.
Hand edits in the UI reported, not silently keptowner · TBD
A dashboard nobody can rebuild is lost with the person who made it, and it is usually the one that mattered during the last incident.
3.4's utilisation dashboard brought under the same treatmentowner · TBD
A dashboard can be recreated in an empty Grafana from the repository aloneowner · TBD

19.1Applications instrumented once, with OpenTelemetry2027-09-10planned · 0/4

OTel SDK replacing the Pinpoint agent, per applicationowner · TBD
Structured logs carrying the trace idowner · TBD
This single change is what lets a log line jump to its trace, and it is what turns three separate signals into one picture rather than three tabs.
A shared library or starter, so each team does not solve this againowner · TBD
Order agreed with the application teamsowner · TBD
This work belongs to the application teams, not to SRE — as do 15.3 and item 26. Three items asking the same people for time at once is the largest coordination surface on the roadmap, and the order is theirs to set.

19.2Old and new side by side, parity verified per service2028-05-19planned · 0/4

Each service dual-running on both stacks before anything is switched offowner · TBD
Parity means last month's incident can be investigated on the new stackowner · TBD
Comparing dashboards side by side is not parity — they can look identical and still fail the only question that matters. Replaying a real investigation is the test.
Dashboards and alerts migrated as code, not rebuilt by handowner · TBD
Sign-off per service, by the team that will have to use itowner · TBD

19.3Elasticsearch and Pinpoint decommissioned2028-11-17planned · 0/4

Clusters silenced first, removed after a stated quarantineowner · TBD
3.2's rule for orphaned VMs, applied here — stopping the answers surfaces whoever was still asking, while putting it back is still possible.
Log retention obligations checked before any log data is deletedowner · TBD
The old cluster may have been quietly satisfying a retention requirement nobody restated when the new stack was designed. Deleting first turns a compliance question into a compliance finding.
Reclaimed compute and storage handed to item 03 accountingowner · TBD
Item 03's milestones are due 2026-12-18, long before this, so no dependency is drawn — the edge would point forward in time. The capacity is still real and still theirs to count.
Grafana is the only place anyone looksowner · TBD

Back to the Platform Roadmap overview · the direction behind these milestones is the Platform Roadmap.