Build your first dashboard

A useful first dashboard answers one question. Start with something you want to understand about your app, such as how request latency changes over time. Your coding agent can choose panels from the telemetry you already have, or you can use the example below.

This guide uses telemetry sent to Everr Cloud. Dashboards, alerts, and runbooks live together in an everr/ directory at your project root and are published with everr apply.

Connect the CLI to Cloud

Run this once and select the organization receiving your app's telemetry:

everr cloud login

Your saved session lets the CLI query telemetry and publish resources. Run everr cloud status to check the installation and organization. To switch installations, run everr cloud login --url <app-url>. See Authentication for session details and Publishing resources for automation.

Use your coding agent

From the project where you installed the Everr skills, ask:

/everr-setup-resources Build a first dashboard from this app's production telemetry in Everr Cloud. Help me understand request latency, errors, and traffic. Preview it so I can review the panels.

The agent inspects your data, writes the dashboard file, checks its queries, and applies it to a preview. Open the printed link to review the result before publishing.

Build it manually

Create everr/ if it doesn't exist. Keep all resources for this repository in that directory. Apply infers the repository identity (repoid) from its Git origin remote. For a project without an origin, see Observability as code.

Check the trace schema:

everr cloud query "DESCRIBE TABLE traces"

Save this as everr/api-latency.dashboard.yaml. Replace my-service with your app's service.name. The example uses server spans from the production environment and excludes failed requests so fast failures don't lower the latency signal.

kind: Dashboard
metadata:
  name: api-latency
spec:
  display:
    name: API latency
  timeRange:
    from: now-1h
    to: now
  panels:
    p99:
      kind: Panel
      spec:
        display: { name: p99 request latency (ms) }
        plugin:
          kind: TimeSeriesChart
          spec: { showLegend: true, valueFormat: { 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
                    WHERE ServiceName = 'my-service'
                      AND Timestamp >= {from:String} AND Timestamp <= {to:String}
                      AND SpanKind = 'Server'
                      AND StatusCode != 'Error'
                      AND toString(ResourceAttributes.`deployment.environment.name`) = 'production'
                    GROUP BY ts
                    ORDER BY ts
  layouts:
    - kind: Grid
      spec:
        items:
          - x: 0
            y: 0
            width: 24
            height: 8
            content: { $ref: "#/spec/panels/p99" }

The panel shows the latency below which 99% of sampled successful requests fall. Duration is stored in nanoseconds, so the query divides by 1e6 to return milliseconds.

• metadata.name is the stable slug used in the dashboard URL. metadata.project is optional and defaults to default.
• {from:String} and {to:String} follow the time picker. {step:UInt32} sets the bucket width to keep the chart readable across time ranges.
• The chart uses the ts column for time and p99_ms for the plotted value. The grid's $ref places that panel on the dashboard.

This example needs server spans with deployment.environment.name set to production. Adapt the filters to your verified instrumentation. See the dashboard spec for more options.

Preview and review

everr apply ./everr --preview

The CLI prints the destination organization, a change summary, and a Preview: link. Open it and check the panel against your service's data. Try a short time range and a longer one to check the query and chart. Preview state is separate from live resources and expires after 7 days without another apply.

The preview name defaults to your current Git branch. If no branch name is available, give it a name, for example everr apply ./everr --preview first-dashboard.

Publish and open

When the preview looks right:

everr apply ./everr

Check the destination organization and the planned changes, then confirm. Open Dashboards in Everr Cloud and select API latency. Its path is /dashboards/default/api-latency.

Keep editing the file to add panels or refine the query. Preview, review, and apply again; keeping the same project and slug updates the existing dashboard. If nothing changed, the CLI prints Nothing to apply.

Apply reconciles the entire directory for this repository identity, across dashboards, alerts, and runbooks. Removing a file and applying deletes its resource. Use one complete apply directory per repository identity so you keep the resources you want to retain.

Next: Create your first alert.