Eight surfaces
Listed in the order the product's own navigation lists them, because that is the order they are used in.
Projects
A project per application or service, each with its own key, quota and retention, pooled under one workspace.
Search
A deliberately small query language (level filters, service and attribute matches, full-text phrases) over months of events, not a search box over the last hour.
Tail
Lines as they arrive, streamed over SSE, in the app or from the CLI. The same view at a desk or in a terminal.
Dashboards
Volume, error rate and p95 latency read from per-minute continuous aggregates, so a chart never scans raw rows.
Errors
Thousands of events fingerprinted into the few groups that matter, with merge, split, and an alert when a fixed group comes back.
Incidents
When errors burst, the builder walks the failing traces, ranks the roots by trace share and onset order, and reverses the call graph to compute the blast radius.
Hub
Every project in the workspace on one service graph, sized by volume and bordered by error ratio, where a failure travelled, not just where it landed.
Usage
What you are ingesting, by project, against the quota, before the invoice, not after it.
What happens to an event
One event, from the call in your process to the incident it ends up in. Each stage is named the way the code names it, so you can go and find it.
Capture
An SDK batches and backs off, redacts at the client, and drops oldest under quota rather than blocking your process. OTLP/HTTP works too, from any collector you already run.
Store
Events land in TimescaleDB hypertables with a server-side redaction backstop, compression, and tiered retention: 30 days hot, 90 tiered, 180 for traces and incidents.
Group
Every error event and failed span is fingerprinted into an error group as it arrives, not on a schedule, and not only when someone opens the page.
Explain
On a burst, the builder finds the deepest failing spans with no failing child, ranks candidate roots, computes observed and predicted blast radius, and an agent writes the explanation.
Act
Hand the incident to a playbook (incident-response or auto-root-cause-analysis), and the rest of e-volv takes it from there. That hand-off is why Observer lives inside a control plane rather than beside one.
How events get in
Three SDKs you can install today, two capture surfaces that are not an SDK at all, and five more written and conformance-tested with no release tag yet.
- JavaScript / TypeScript
npm install @e-volv/logs0.1.1 - Python
pip install e-volv-logs0.1.0 - Go
go get github.com/e-volv/logs-gov0.1.0 - Edge runtimes@e-volv/logs/edge ships in the same package, a fetch-only client for Cloudflare Workers, Vercel Edge and Deno Deploy, where the Node entry cannot run. Docs
- OpenTelemetryOTLP/HTTP ingest from any collector you already run, so a team with existing instrumentation adopts Observer without touching a service. Docs
- Java / JVMNot in serviceLogback appender, servlet filter, Spring Boot starter
- Swift / iOSNot in serviceCrash and signal capture, disk queue, URLSession
- RubyNot in serviceRack middleware, Rails.logger bridge, ActiveJob carriers
- RustNot in serviceA tracing Layer, sync and Tokio
- React NativeNot in serviceJS layer verified; native module written
Point a service at it
Observer is its own plan and its own bill. Run it beside the workflow engine or entirely on its own.
Agents? See e-volv Berserker, agent observability and evals, included with Observer’s paid tier.