Devlog #3: Production telemetry, cloud SQL, and a shared logs explorer

Four weeks since the last devlog. This batch expands Everr in two directions: it now accepts production OpenTelemetry alongside CI data, and the data (cloud and local) is queryable through read-only SQL surfaces. A shared logs explorer sits on top of both, and bundled skills let coding assistants reach for the new surfaces on their own.

Devlog #2 introduced the local observability stack as a v1 with a small set of canned queries. In daily use we kept wanting to ask both that and the cloud data more interesting questions, from scripts, from the CLI, and from inside the desktop app, and the bigger goal of letting an assistant debug on its own was bottlenecked on the same thing. So most of this cycle went into fixing that, plus opening up the cloud side to data that doesn't come from CI.

Here's what shipped.

Production telemetry

Everr's cloud side now accepts OpenTelemetry data from any service that speaks OTLP, not just CI.

See the Production Monitoring docs for the full setup.

everr cloud query for SQL access to your runs

everr cloud query "<SQL>" lets you run read-only ClickHouse queries against your own org's data from the CLI. Same shape and dialect as the local SQL surface below, just pointed at cloud data instead of local.

Making this safe took most of the work. Each org now gets its own ClickHouse role with hashed name, the /sql route enforces read-only mode, execution timeouts, query quotas, and per-tenant isolation through the existing row-level policy. We also backfilled access for existing tenants and dropped the dedicated SQL user in favor of role-based auth.

It's a deliberately small surface, read-only, quota'd, no DDL, but it's enough for an assistant or a power user to answer questions like "show me flaky failures on main last week" without us having to ship a new endpoint for every shape of question.

A logs explorer in both the web app and the desktop app

On top of that storage layer we built a logs explorer. It has a draggable histogram, level filters, fast text search, a detail panel, and the usual time-range and refresh controls. The point isn't the UI, there are plenty of log viewers in the world, it's that it works against both surfaces:

• In the web app, against our cloud ClickHouse, for CI and ingested workflow logs.
• In the desktop app, against the local chDB instance, for whatever you've sent into your local collector.

To make that possible without two implementations, the explorer lives in the shared @everr/telemetry-explorer workspace package, with a SqlClient interface and a LogsRepository that both surfaces wire up to their own backend. The web app talks to it through server functions; the desktop app talks to it through a Tauri command that calls the local SQL endpoint. Same UI, same query builders, same schemas, different transport.

Day to day it means the logs view is no longer a CI-only feature. If you've pointed any local service at the collector, you can open the desktop app and watch its logs there.

everr wrap for arbitrary commands

everr wrap -- <command> runs any command and mirrors its stdout/stderr into local telemetry while still printing it to your terminal. The command's exit code is preserved, so it slots into scripts and Makefiles without changing behavior, and it refuses to run if the local collector isn't up so you don't silently lose data.

The motivating use case is the same as the rest of this work: getting more runtime context in front of agents. A test run, a dev server, a one-off script, wrap it and the output is queryable from the same place as your OpenTelemetry data, instead of being lost the moment the terminal scrolls.

A consolidated local telemetry stack

We also rebuilt the local telemetry storage so the logs explorer, everr wrap, and everr local query can all sit on top of the same SQL surface. The local collector now embeds chDB, an in-process build of ClickHouse, as its storage backend, and exposes an HTTP SQL endpoint that the CLI and desktop app can hit directly.

In practice that means local OTLP data lands in something that looks and queries like our cloud ClickHouse, with no separate process to run. You can throw arbitrary read-only SQL at it from everr local query, and the desktop app can render charts and tables against the same data without going through a custom RPC. Retention is configurable per tenant and capped to keep the on-disk footprint small.

The collector itself got a redesign to support this. We rebuilt the chDB exporter, moved the SQL endpoint behind a new local gateway, and reworked startup so the collector can be embedded in the CLI binary without bringing along a separate sidecar. None of this is visible from the outside, but it makes the next round of features cheaper to build.

Bundled skills and an installer

We moved away from injecting Everr's instructions into the project's AGENTS.md and shipped everr skills instead. It installs a small set of bundled skills (CI debugging, local telemetry setup, local debugging) into Claude Code, Codex, or Cursor, globally by default, or per project. everr skills update keeps them in sync as we improve them.

The change is deliberate. AGENTS.md content is always loaded into the assistant's context; skills activate only when their description matches what the assistant is actually doing, or when you invoke them explicitly. The result: skills fire less often overall, but they're available the moment you (or the assistant) hit a CI failure or a missing-trace situation, and the rest of the time, they're not eating into the context budget. We think that's a better DX in both directions: lighter by default, explicit when you need it.

The skills themselves describe how to set up local telemetry when it's missing, how to read it once it's there, and how to drive everr ci from inside a debugging session. When an assistant hits a failing test in a repo with Everr installed, it has a path to runtime context that doesn't depend on a human pasting things into the prompt.

Desktop releases through GitHub and a SHA-based identity

The desktop app now releases through GitHub Releases, with a build-and-sign workflow that signs and notarizes the DMG before staging artifacts. Release identity is keyed off the commit SHA rather than a hand-bumped version, which means we can ship pre-release builds without inventing version numbers, and the docs site serves redirects to the right artifact instead of hardcoding URLs.

This isn't visible to users beyond "downloads work and updates are signed," but it's what makes the desktop app actually shippable on a regular cadence.

Other improvements in the same direction

Onboarding-focused home. The web app's home is now built around getting started: a prominent "Install Everr" card, the rest stripped down. The dashboard overview that used to live there has been replaced by surfaces that better fit how people actually use the app once they're past day one.

everr ci watch --run-id and everr ci status --run-id. Both commands now accept a specific run id, not just the current HEAD commit. Useful when you're scripting against a known run or following up on a specific failure.

CLI reorganization. We grouped commands under their domains, everr ci status, everr ci watch, everr ci logs, everr cloud login, everr local query, and so on, and removed the standalone everr ci grep command in favor of the more general everr ci logs --egrep. The CLI guidelines doc we wrote last cycle is now driving these calls.

Removed unread tracking from the desktop app. The unread badge and seen-runs tracking were more friction than signal in daily use, so we removed them. Notifications themselves stayed; the bookkeeping around "have you looked at this yet" went away.

Live "When" column. The runs list now ticks its relative timestamps in real time and refetches in the background, so a tab that's been open for a while stays accurate instead of drifting until you click around.

Billing with Polar. We integrated Polar for subscriptions. Pricing isn't on the landing page right now, we pulled it for a narrative refresh, but the plumbing is in place behind the scenes.

What's next

We've now got production OTel ingest, the same SQL surface on the local collector and the cloud, a shared logs explorer that consumes both, a way to feed arbitrary commands into the local stack, and skills that tell assistants how to use it all.

The next batch is about turning that shared telemetry layer into a fuller working loop. Logs got the explorer this cycle; traces and metrics need the same treatment, and the OpenTelemetry setup needs a shorter on-ramp for both the local collector and cloud ingest. The goal is for a developer, or an assistant, to get from "something is running" to useful runtime context without first becoming an observability expert.

We also want the local and cloud sides to start helping each other. That means forwarding slices of local telemetry when a teammate or cloud agent needs to see what happened on your machine, bundling a collector into the Everr GitHub Action so CI-time telemetry becomes a one-liner, and tracking deploys as first-class events. With production telemetry now landing, the missing piece is the deploy itself: when a version went out, where it ran, and how a production regression connects back through CI to the commit that caused it.

Same pattern as before: the things we hit in daily use keep turning into PRs the same week.