Observability made simple.
For real.

Setting up observability shouldn’t take days. Get started in minutes.

curl -fsSL https://everr.dev/install.sh | sh

The Everr app showing a Kubernetes infrastructure dashboard with CPU, memory, and pod metrics

Capabilities

See what your code actually does.

Everything you need to go from a fast local feedback loop to production observability — one OpenTelemetry pipeline, end to end.

Logs, traces, metrics, and errors. All OpenTelemetry.

Every signal is standard OpenTelemetry, so one model covers your laptop, CI, and production.

Dashboards, Alerts, Error tracking; All you expect from a modern observability platform.
Runbooks for incident response, automated remediation, and root cause analysis
Correlation all the way from logs to traces to metrics

An uncaught exception grouped into an issue and linked to its trace

A request rendered as a trace waterfall of spans

A metrics dashboard built from OpenTelemetry data

Plain SQL from the CLI, local or cloud

Read what actually ran without learning a query language. Run everr local query against your own machine or everr cloud query against the shared workspace, the same SQL and the same tables whether the data is on your laptop or in production.

Plain SQL over ClickHouse, local and cloud
The same query your coding agent runs

~/checkout-service · zsh

$ everr cloud query "
  SELECT
    service,
    round(quantile(0.5)(value))  AS p50,
    round(quantile(0.95)(value)) AS p95
  FROM metrics
  WHERE name = 'http.server.duration'
  GROUP BY service
  ORDER BY p95 DESC"

┌─service──┬─p50─┬─p95─┐
│ payments │ 120 │ 610 │
│ checkout │  84 │ 470 │
│ search   │  22 │  90 │
│ auth     │   9 │  38 │
└──────────┴─────┴─────┘

$ ▋

Your telemetry right where the work happens

A desktop companion app runs a local OpenTelemetry collector and allows you to explore, query, and verify your telemetry locally, without the need for tedious deployment loops.

Runs an embedded OpenTelemetry collector on launch, no cloud account needed
Available for macOS and Linux

The Everr desktop app exploring local telemetry

Dashboards, alerts, and runbooks as code

Define your dashboards, alerts, and runbooks as files in your repo, so you and your coding agent know where to look before you even open Everr. The config doubles as documentation — and as memory your agent reads to find what matters.

Perses-format dashboards and query-driven alerts
Runbooks are Markdown, living next to the alert they belong to, so configuration becomes your knowledge base

runbooks/infra-health.yaml

kind: Runbook

metadata:

name: infra-health

project: default

spec:

display:

name: "Infrastructure & Internal Collector Health"

description: "Triage runbook for the internal kubelet-stats collector."

duration: 1h

refreshInterval: 30s

panels:

freshness:

kind: Panel

spec:

display: { name: Metrics lag (seconds since last datapoint) }

plugin:

kind: StatChart

spec:

calculation: last

unit: "s"

colorMode: background

thresholds:

defaultColor: "#22c55e"

steps:

- { value: 120, color: "#f59e0b" }

- { value: 300, color: "#ef4444" }

queries:

- kind: ClickHouseSQL

spec:

plugin:

kind: ClickHouseSQL

spec:

query: |

SELECT dateDiff('second', max(TimeUnix), now()) AS lag_seconds

FROM metrics_gauge

WHERE TimeUnix >= {from:String} AND TimeUnix <= {to:String}

AND MetricName = 'k8s.node.cpu.usage'

CI you can query

A GitHub App turns every Actions run into structured, queryable data: workflows, jobs, steps, and per-test spans. Every run is a trace and every job carries its cost, so you can optimize for performance, cost, or both.

Workflows, jobs, and steps as queryable traces
Per-test spans for slow and flaky tests
Estimated cost attributed by job, workflow, and runner
Get notified when a workflow run fails

ci.yml · run #18424m 18s

build2m04

checkout14s

install48s

test1m02

lint38s

deploy1m00

flaky tests · 30d

auth.login2 flaky

pool.acquire1 flaky

cart.checkoutstable

upload.large3 flaky

Built for coding assistants

Everr is built for your coding assistant as much as for you. Bundled skills teach it when to reach for telemetry and how to query it, working from your repo so it ties a failing trace or log back to the code that caused it.

Crafted skills to help your assistant work with telemetry
One install, available in every assistant you use
Fixes grounded in real traces and logs, not guesses

everr-use-telemetry / SKILL.md

1---

2name: everr-use-telemetry

3description: Use when investigating logs, traces, metrics, errors.

4---

6# Use Telemetry With Everr

7Use Everr telemetry before guessing at runtime behavior.

9## Only Raw SQL

10The only query command is raw SQL:

11`everr cloud query "<SQL>"` or

12`everr local query "<SQL>"`.

14## Choose The Source

15| Question | Use |

16| Production, customer reports | cloud |

Quick start

Days of setup, or one command.

Setting up observability usually means a long detour full of context switches. With Everr the feedback loop is immediate.

The old way

01Hand-instrument every service
02Settle on attribute names
03Get trace context to propagate
04Stitch logs to traces by hand
05Build dashboards from scratch
06Decide what to alert on
07Debug why no data shows up

~3 daysto first signal

With Everr

$ curl -fsSL https://everr.dev/install.sh | sh

everr CLI installed

agent skills installed

local collector ready

first trace received

The everr installer sets up the CLI, agent skills, and a local collector. The collector lets you build and validate telemetry locally; the skills let your coding agent instrument the codebase and take it to production.

minutesto first signal

Same pipeline, none of the setup. Skip the plumbing and go straight to the data.

Read the quickstart

Built for agents

Same task. One side is guessing.

Hand your coding agent a bug and it reasons from the code alone: plausible, confident, and often wrong.

Without Everr

reasoning from code only

checkout is throwing 500s, investigate and fix it.

Reading checkout.ts …
The order-items query has no index.
Under load, that's the bottleneck.
Adding an index on order_id.

Proposed fix

+ CREATE INDEX idx_items_order
+   ON order_items (order_id);

no evidence · didn't fix the outage

With Everr

grounded in what ran

checkout is throwing 500s, investigate and fix it.

On it. Let me check what actually ran in prod first.

$ everr cloud query "SELECT ResourceAttributes['service.version'] AS version, count() FROM traces WHERE ServiceName = 'checkout' AND StatusCode = 'Error' GROUP BY version"

37 errors · all on a1f3c9d

$ everr cloud query "SELECT Body, count() FROM logs WHERE ServiceName = 'checkout' AND SeverityText = 'ERROR' GROUP BY Body"

37× “DB pool exhausted: 10/10 in use”

All ten connections are in use, so the pool is my bottleneck. Commit a1f3c9d scaled checkout out to more workers but left the pool at 10, so requests queue for a connection, hit the acquire timeout, and 500. I'll raise the cap to match the workers.

db.ts+1-1

pool: { max: 10 }

pool: { max: 50 } // saturated since a1f3c9d

Before I ship, I'll reproduce it locally, replaying the load against the patched pool and checking again with everr.

$ everr local query "SELECT count() FROM traces WHERE ServiceName = 'checkout' AND StatusCode = 'Error'"

0 errors

fix confirmed

Reading code tells half the story. Everr gives you the half you are missing.

Wire it into your agent

Built on open standards

Open standards, top to bottom. No lock-in by design.

Everr doesn't invent a private model. Your telemetry is OpenTelemetry, your dashboards and alerts are plain files, and you query all of it with SQL.

Standard OpenTelemetry

Traces, logs and metrics in one open model — the same signal from your laptop to CI to production.

overview.dashboard.yaml

1kind: Dashboard

2metadata:

3name: overview

4project: demo

5spec:

6panels:

7requests:

8kind: Panel

9spec:

10display:

11name: Requests / sec

12plugin:

13kind: TimeSeriesChart

14queries:

15- kind: ClickHouseSQL

16spec:

17plugin:

18kind: ClickHouseSQL

19spec:

20query: |

21SELECT

22toStartOfInterval(Timestamp,

23INTERVAL {step:UInt32} SECOND) AS ts,

24count() AS value

25FROM traces

26WHERE Timestamp >= {from:String}

27AND Timestamp <= {to:String}

28GROUP BY ts

29ORDER BY ts

30layouts:

31- kind: Grid

32spec:

33items:

34- width: 24

35height: 8

36content:

37$ref: "#/spec/panels/requests"

Perses dashboards

The open CNCF dashboard spec, versioned as plain files — not locked in a UI.

Query with SQL

One read-only SQL surface over every signal — no query language to learn, the same locally and in the cloud.

service.name=checkout

trace_id=a3f9…c1

span.kind=server

http.route=/cart

db.system=postgres

url.path=/orders

http.request.method=GET

http.response.status_code=200

db.operation=SELECT

deployment.environment=prod

server.address=10.0.1.4

messaging.system=kafka

rpc.method=Charge

error.type=timeout

Semantic conventions

Everr reads the OpenTelemetry attributes your code already emits, so traces, logs, and metrics correlate on their own.

Add p99 latency panel to checkout

Claude·overview.dashboard.yaml

3f9a2c1

Lower checkout error-rate alert to 2%

Claude + Gio·checkout-errors.alert.yaml

b7e10d4

Write payments-timeout runbook

Gio·payments-timeout.runbook.md

5c81a9f

Rename cart-api panels after refactor

Codex·cart-api.dashboard.yaml

a204e6b

Dashboards, alerts & runbooks as code

Open, inspectable files in Git — people and agents edit them side by side, reviewed and versioned like the rest of your code.

See how it fits together

FAQ

Questions worth answering

Still curious? Ask us on Discord.

Community

Talk to the team.
Shape what ships next.

It's where we talk with the people using Everr. Drop feature requests, share feedback, and weigh in on what we build next.

Join Us on Discord

Stop guessing.
Start observing.

curl -fsSL https://everr.dev/install.sh | sh

Observability made simple.For real.

See what your code actually does.

Logs, traces, metrics, and errors. All OpenTelemetry.

Plain SQL from the CLI, local or cloud

Your telemetry right where the work happens

Dashboards, alerts, and runbooks as code

CI you can query

Built for coding assistants

Days of setup, or one command.

The old way

With Everr

Same task. One side is guessing.

Without Everr

With Everr

Open standards, top to bottom. No lock-in by design.

Standard OpenTelemetry

Perses dashboards

Query with SQL

Semantic conventions

Dashboards, alerts & runbooks as code

Questions worth answering

Talk to the team.Shape what ships next.

Stop guessing.Start observing.

Observability made simple.
For real.

Talk to the team.
Shape what ships next.

Stop guessing.
Start observing.