Observability as code

Observability as code means your dashboards, alerts, and runbooks are files in your Git repository, not settings you click together in a UI. They are YAML, applied to Everr with everr apply, and rendered read-only by the app. Git is the source of truth: a resource changes when a file changes and you apply it. There is no click-to-edit, no save button, no in-app authoring.

What lives as code

Three kinds of resource, all plain files:

• Dashboards are YAML. The app runs the panel queries and draws the charts.
• Alerts are YAML with a query. The app runs the query on a schedule, and every row it returns is a firing instance.
• Runbooks are Markdown, with any panels embedded live, applied next to the alert they belong to.

kind: Dashboard
metadata:
  name: api-latency
spec:
  panels:
    p99:
      kind: Panel
      spec:
        plugin: { kind: TimeSeriesChart, spec: { unit: ms } }
        queries:
          - kind: ClickHouseSQL
            spec:
              plugin:
                kind: ClickHouseSQL
                spec:
                  query: SELECT toStartOfInterval(Timestamp, INTERVAL {step:UInt32} SECOND) AS ts, quantile(0.99)(Duration) / 1e6 AS p99_ms FROM traces GROUP BY ts
  layouts:
    - kind: Grid
      spec:
        items:
          - { x: 0, y: 0, width: 24, height: 8, content: { $ref: "#/spec/panels/p99" } }

Why files instead of forms

• Reviewed in pull requests. Changes land through the same review as your code, so a bad alert gets caught before it ships.
• Versioned with your code. History, blame, and rollback come for free. You can see who changed a threshold, and when.
• Reproducible anywhere. The same files produce the same resources in every environment, with no clicking to recreate a setup.
• Readable by your agents. The queries in these files show a coding assistant exactly how to retrieve your telemetry: which tables, columns, and filters matter for your system. A UI hides all of that.
• Yours to keep. Open files in your repo, not configuration locked inside one product.

How to do it

Start here:

• Build your first dashboard
• Create your first alert
• Add a runbook
• Publishing resources covers everr apply and the everr/ directory.

Then the specifics:

• Writing good alerts
• Link alerts to runbooks

For the exact file formats, see the Dashboard spec, the AlertRule spec, and the Runbook spec.