Observability Without Owner

A page arrives at 03:00. The on-call engineer opens the runbook linked in the alert. The runbook is a Markdown file in the observability repository. The file has not been updated in two years. The instructions reference a service that was renamed twelve months ago. The dashboard URL in the runbook returns a 404. The engineer pages the secondary on-call. The secondary does not know the service either. The engineer pages the manager. The manager pages the team that used to own the service. The team that owns the service now is on a different continent. The incident lasts two hours. The post-incident review identifies the root cause as the runbook had no owner.

This is the observability without owner anti-pattern. The pattern is not the absence of dashboards, alerts, or runbooks. The pattern is the absence of a named human who is responsible for keeping them accurate. Telemetry without an owner decays. Decayed telemetry pages the wrong person with the wrong information at the wrong time.

What it is

The observability without owner anti-pattern is the practice of deploying dashboards, alerts, and runbooks without assigning a named team or human to keep them current. The owner is the person who, when the dashboard stops reflecting reality or the runbook stops reflecting the system, takes the call to fix it.

Four telemetry artefacts require owners:

1. Dashboards. A dashboard owner reviews the panels quarterly, prunes panels that have no consumer, adds panels that answer recurring investigation questions, and confirms the data sources still resolve.
2. Alerts. An alert owner confirms the alert has fired accurately in the past ninety days, the runbook is current, the severity is consistent with the receiver, and the threshold is still meaningful.
3. Runbooks. A runbook owner confirms the linked dashboards resolve, the commands still execute against the current system, the escalation path is current, and the documented recovery action still works.
4. Metrics. A metric owner confirms the metric has a consumer, the cardinality bound is enforced, the retention is documented, and the alert or dashboard that consumes it is owned by the same team.

Compare to the alternative: telemetry with named owners. The owner is a team in the CODEOWNERS file, a team label on the dashboard JSON, an owner annotation on the alert rule, and a contact in the runbook frontmatter. The owner is consulted when the artefact is created, consulted when it is modified, and held accountable when it is broken.

The trade-off is honest. Named ownership costs you the flexibility of “anyone can change anything”. An artefact with a named owner requires the owner’s review to modify. The mitigated risk is the artefact decaying into a wall display that nobody trusts.

Why a sysadmin cares

Unowned telemetry fails in five measurable ways, all of which hit the operator on call.

The wrong team is paged. An alert for a service that was renamed six months ago still pages the old team. The old team has been dissolved. The page reaches a forwarding address. The page sits in a queue for four hours.

The runbook points to nothing. The runbook URL returns a 404. The dashboard URL returns “permission denied”. The escalation path contacts a Slack channel that has been archived. The operator is on their own.

The dashboard has not been updated. The dashboard panels reference metrics that have been renamed or removed. The operator opens the dashboard to investigate; every panel shows “No data”. The operator falls back to curl and jq.

The alert has not been tuned. The threshold was set when the service was small. The service has grown ten times. The alert fires every fifteen minutes during traffic peaks. The operator silences the alert. The next real incident is silenced too.

The metric has no consumer. The metric is emitted by the default instrumentation. The team that wrote the service has been reassigned. The metric has been scraped for two years. No dashboard references it. No alert depends on it. It consumes storage and produces nothing.

How it works

The ownership discipline is a continuous loop, not a one-time assignment. The loop has four steps, run quarterly.

1. Assign
   - Every dashboard has a team label
   - Every alert has an owner annotation
   - Every runbook has an owner field in frontmatter
   - Every metric has a consumer-contract document
        |
        v
2. Audit
   - Top dashboards by last-modified date
   - Top alerts by last-fired date
   - Top runbooks by last-reviewed date
   - Top metrics by consumer count
        |
        v
3. Remediate
   - Reassign orphaned artefacts to the team that owns
     the underlying service
   - Delete artefacts that have no consumer
   - Update artefacts that have drifted from reality
        |
        v
4. Verify
   - CODEOWNERS file is in version control
   - Dashboard JSON has team labels
   - Alert rule has owner annotation
   - Runbook frontmatter has owner field

The loop is documented; the audit is scheduled; the remediation is owned. The platform’s ownership posture is the ratio of artefacts with owners to artefacts in the repository. The ratio is reported in the quarterly platform review.

How to configure it

The configuration is four parts. The CODEOWNERS file enforces review on changes. The dashboard JSON labels the owner. The alert rule annotates the owner. The runbook frontmatter documents the owner.

# /.github/CODEOWNERS
# Severity: CONFIGURATION

# Dashboards
/dashboards/checkout/      @team-checkout
/dashboards/payments/      @team-payments
/dashboards/infrastructure/ @team-sre

# Alert rules
/rules/                    @team-sre
/rules/team-checkout/      @team-checkout
/rules/team-payments/      @team-payments

# Runbooks
/runbooks/                @team-sre
/runbooks/checkout/       @team-checkout
/runbooks/payments/       @team-payments

# Collector configuration
/etc/alloy/               @team-sre

The matching Grafana dashboard annotation:

{
  "title": "Checkout Availability",
  "uid": "checkout-avail",
  "tags": ["checkout", "availability", "team-checkout"],
  "schemaVersion": 39,
  "annotations": {
    "list": [
      {
        "name": "dashboard-owner",
        "type": "constant",
        "value": "team-checkout"
      }
    ]
  }
}

The matching Prometheus alert rule annotation:

- alert: HighErrorBudgetBurn
  expr: |
    sum(rate(http_requests_total{job="checkout",status=~"5.."}[5m]))
    /
    sum(rate(http_requests_total{job="checkout"}[5m])) > (14.4 * 0.001)
  for: 2m
  labels:
    severity: critical
    owner: team-checkout
  annotations:
    summary: 'Checkout error budget burning at 14.4x'
    description: '...'
    runbook_url: 'https://runbooks.example.com/checkout-availability'

The matching runbook frontmatter:

---
title: 'Checkout Availability Runbook'
owner: team-checkout
contact: '#team-checkout'
escalation: '#on-call-rotation'
last_reviewed: '2026-08-13'
last_tested: '2026-08-13'
---

## Symptoms
...

The four configurations share a discipline: the owner is named, the owner is contactable, the owner has reviewed the artefact within the last quarter.

How to validate it

Four commands confirm the ownership posture is healthy.

# 1. CODEOWNERS file coverage. The audit of audit.
# Severity: READ-ONLY
grep -E '^/(dashboards|rules|runbooks|etc/)' \
  /home/ebrandi/projects/observability/.github/CODEOWNERS \
  | wc -l

A count above zero confirms the CODEOWNERS file exists and covers the artefact paths.

# 2. Dashboards with team labels. The coverage audit.
# Severity: READ-ONLY
for f in /home/ebrandi/projects/observability/dashboards/**/*.json; do
  owner=$(jq -r '.annotations.list[]? | select(.name=="dashboard-owner") | .value' "$f")
  echo "${f}:${owner:-MISSING}"
done \
  | grep -E ':MISSING$'

A non-empty result is the list of unowned dashboards. The list is the remediation backlog.

# 3. Alert rules with owner labels.
# Severity: READ-ONLY
grep -L 'owner:' /home/ebrandi/projects/observability/rules/**/*.yml

A non-empty result is the list of unowned alerts.

# 4. Runbooks with owner frontmatter.
# Severity: READ-ONLY
grep -L '^owner:' /home/ebrandi/projects/observability/runbooks/**/*.md

A non-empty result is the list of unowned runbooks.

How it can fail

Five shapes recur when the ownership discipline lapses.

1. The renamed-service orphan. A service is renamed. The dashboards, alerts, and runbooks are not renamed. The service is owned by the new team; the artefacts are owned by the old team. The old team does not know the service.
2. The dissolved-team orphan. A team is dissolved. The artefacts the team owned are not reassigned. The CODEOWNERS file still references the team; the team no longer exists. The PR review request is undeliverable.
3. The dashboard-stagnation drift. A dashboard is created. No one reviews it. The underlying metrics change. The dashboard shows “No data”. The dashboard is not deleted because deleting it requires knowing it exists.
4. The alert-runbook mismatch. An alert is updated. The runbook is not. The runbook references the old threshold. The operator follows the runbook; the threshold does not match; the operator is uncertain whether to escalate.
5. The contractor-handoff gap. A contractor built the dashboard and the runbook. The contractor left. The internal team does not know the artefact exists. The artefact is not in CODEOWNERS because the contractor did not add it.

How to troubleshoot it

1. Run the four audit commands above; collect the unowned
   artefact list
        |
        v
2. For each unowned artefact, identify the team that owns
   the underlying service
        |
        v
3. Assign the artefact: update CODEOWNERS, update dashboard
   labels, update alert annotations, update runbook
   frontmatter
        |
        v
4. Notify the new owner; confirm the contact channel is
   current
        |
        v
5. Verify the artefact appears in the next quarterly audit
   as owned
        |
        v
6. Document the audit cadence; schedule the next audit

Security implications

Unowned telemetry is also a security liability. A dashboard with no owner may expose sensitive metrics (user identifiers, internal hostnames) without anyone noticing. An alert with no owner may fire on a security event that no one is responsible for triaging. A runbook with no owner may document a recovery procedure that is now wrong because the underlying service has been hardened. The ownership audit is the surface where the security audit and the telemetry audit intersect.

Performance implications

The ownership audit is a quarterly operation; the cost is operator time. The cost is bounded by the artefact count and the team count. The audit can be partially automated (the four commands above cover the structural attributes) but the remediation (reassigning the artefact to the right team) requires a human. The cost of the human review is the investment; the cost of not investing is the incident MTTR.

Verification

You should now be able to answer:

• What are the four telemetry artefacts that require owners, and what does each owner do?
• Why is unowned telemetry a liability rather than an asset?
• Where in the repository is the ownership information stored for dashboards, alerts, runbooks, and metrics?
• What is the quarterly audit loop, and what is the remediation for an unowned artefact?

Quiz