Full-stack observability that never leaves your firewall
Ultraviolet Observability runs entirely inside your environment. Capture traces, logs, metrics and service topology with no code changes — and every byte of that telemetry stays on your infrastructure. No vendor egress. No per-GB surprise. Works air-gapped.
Every other vendor asks you to ship production out the door.
Datadog and Groundcover are good products with the same structural problem: your telemetry — request payload shapes, internal hostnames, customer identifiers leaking through log lines — has to leave your perimeter to be useful. For regulated, defense, and on-prem workloads, that is where the evaluation ends.
01
Your data stays yours
Traces, logs and metrics are stored inside your network and queried from inside your network. There is no vendor pipeline to trust, no DPA to negotiate over telemetry contents, and no third-party breach that can expose your production internals.
No telemetry egress
Customer-owned storage
02
Works with no internet at all
The core is offline-first, not offline-tolerant. Every feature — ingest, query, dashboards, alerting — functions on a cluster that has never resolved a public DNS name. Air-gapped installs run on a hand-carried signed license.
Air-gap licensed
Zero call-home dependency
03
Retention you actually control
Storage lives on your disks under a retention policy you set. Keeping 90 days of full-fidelity spans is a hardware decision, not a line item — so nobody has to argue about sampling rates to hit a budget.
No per-GB ingest bill
No forced sampling
The only thing that ever crosses your firewall is a license heartbeat — node counts and an expiry date. Never a span, never a log line.
The platform
Full-stack visibility, without touching your application code.
Traces, logs, metrics, infrastructure and more — captured with no code changes, stored on infrastructure you operate, and explored through one interface.
Distributed traces & APM
Every request is captured as a request/response transaction with real latency, status codes and errors — across HTTP, gRPC, DNS, Postgres, MySQL, Redis, Kafka and MongoDB. No SDKs, no sidecars, and no redeploy to start collecting.
Per-route RED — rate, errors, duration
Full distributed trace waterfalls
Language-agnostic — nothing added to your code
Metrics pipeline
Metrics land alongside your traces and logs, with OpenTelemetry, Prometheus remote-write and Fluent Bit all pointing at one place.
Prometheus remote-write
Fluent Bit ingest
Metric-based alerts
Logs, correlated to traces
Log ingest with severity facets, live tail and full-text search — pivoting both directions between a log line and the trace that produced it.
Trace ID correlation
Severity floor filters
Live tail
Service map from real traffic
Topology derived from the calls your services actually make, not a config file someone forgot to update. Edges carry call volume, latency and byte flow.
Live topology
Client → dependency edges
Cross-site rollups
Kubernetes & infrastructure
Node and workload health with a live Kubernetes object inventory, so you can see the cluster behind the request.
Nodes & workloads health
K8s object inventory
Unhealthy-workload surfacing
Dashboards & SLOs
Build dashboards over any signal, track SLOs with error budgets and burn-rate alerts, and import the Datadog dashboards you already have.
Drag-in widgets
Error-budget burn alerts
Datadog dashboard import
Alerting that stays local
Rules are evaluated inside the core on the same signals the dashboards use, then routed to the tools your team already watches.
Error rate · p95 · throughput
Slack · PagerDuty · Teams · email
Durable firing history
Real user monitoring
Browser performance, Core Web Vitals and JS errors with session replay — stitched to the backend trace behind each slow page. Masking is on by default; the DOM never leaves your infrastructure.
Core Web Vitals
Session replay
Browser → backend trace stitch
One core, many sites
Remote clusters dial home over outbound mTLS. No inbound ports at the edge, and site_id is a first-class dimension in every query.
Outbound-only, port 443
Buffered across WAN blips
Per-site + fleet views
OpenTelemetry-native
Ultraviolet speaks OTLP over gRPC and HTTP. Anything you have already instrumented — an SDK, a Collector — points at it and lands in the same store.
No proprietary agent protocol
Traces, logs & metrics, one pipeline
Nothing to rip out
Shipping next
Synthetic monitoring & uptime checks
Architecture
The whole stack runs on your side of the boundary.
One core per customer — no multi-tenancy, no shared storage, no shared query layer. Remote sites dial in; we run nothing but a license desk.
Your perimeter
Remote sites
site: dc-eastcollectors · edge buffer
site: dc-westcollectors · edge buffer
site: factory-07collectors · edge buffer
no inbound ports at the edge
outbound mTLS
Customer-owned core
Collectionall signals · no code changesOTLP-native
Storagetraces · logs · metrics · your retentionYour disks
Air-gapped? Skip this entirely — carry in an annual license file and reconcile usage with a signed export.
Compare
The same depth. A different trust boundary.
Groundcover proved that automatic instrumentation beats hand-written SDKs, and that keeping data in your own cloud beats shipping it to a vendor. We take the last step: the platform itself runs inside your environment, so nothing about it depends on us being reachable.
Deployment model comparison between Ultraviolet Observability, Groundcover and Datadog
Ultraviolet
Groundcover
Datadog
Where telemetry is stored
Your cluster, your disks
Your cloud account, vendor-operated
Vendor cloud
Vendor-managed control plane required
No — the core is yours
Yes — SaaS control plane
Yes — fully SaaS
Runs fully air-gapped
Yes, licensed option
No
No
Instrumentation
Automatic — no code changes
Automatic — no code changes
Agent + APM libraries per language
Retention policy owner
You — retention you set
You, within vendor tooling
Vendor plan tiers
Billing unit
Node-minutes, committed + overage
Nodes
Hosts + ingested GB + indexed spans
Cost of keeping more data
Disk
Your cloud storage
Metered per GB and per span
What crosses your firewall
License heartbeat only
Control-plane metadata + queries
All telemetry
Scroll the table sideways to see every column →
Comparison reflects each vendor's publicly documented deployment model. Product capabilities move quickly — we're happy to walk through a current, specific side-by-side on a call.
Pricing
Priced on what ran, not on what you collected.
We sample your active node set every 30 seconds and sum it into node-minutes. Ingest volume, span count, retention window and cardinality are all free — they cost disk you already own, not a metered line item.
Evaluation
Free30 days
A full-function core in your own cluster. Not a hosted sandbox — the real thing, on your nodes.
A node counts while a collector on it is alive — an installed-but-idle node still meters, a node that scaled down at 14:03 stops metering at 14:03. Usage rolls up in an append-only ledger inside your core, visible to you on the license page before it is ever visible to us.
active nodes
142
committed
200
node-min MTD
1.9M
meter & warn — capacity never blocks ingest
Questions
The things engineers actually ask.
If yours is not here, we would rather answer it directly than write around it.
If the core runs on our hardware, who operates it?
You do — it installs as a Helm chart and runs like any other workload in your cluster. We size it with you, ship signed images and charts, and support upgrades. There is no hidden dependency that phones us for the core to function.
How much overhead does collection add?
Collection is lightweight and needs no code changes, no sidecars and no libraries added to your services. It reads only a bounded prefix of each request — never whole payloads — so a busy node typically stays under one percent of a core, with no build step or compiler required on your nodes.
Do we have to instrument our applications?
No. Traces across HTTP, gRPC, DNS and the major databases are captured with no code changes. If your services already emit OpenTelemetry, point them at Ultraviolet and those spans and logs land in the same store, correlated by trace ID.
What actually happens if our license expires?
It degrades, it does not crash. Past expiry you enter a grace window with full function and a renewal banner — on a connected core the auto-renewal normally closes it before anyone notices. Past the hard stop, ingest keeps running (it is your data on your disks; we will not blind you) and the UI locks to the license page until a fresh license is dropped in.
How does billing work if we are air-gapped and you cannot see our usage?
Your core keeps an append-only usage ledger locally. At renewal you export it as a signed report and we reconcile. Capacity is soft — going over your committed nodes produces a warning in the product and a line on the true-up, never a block on ingest.
Can one core serve multiple sites or clusters?
Yes. Remote sites dial the core over outbound mTLS on 443 — no inbound ports at the edge — and buffer to disk so a WAN outage delays data rather than losing it. Every span carries a site_id, so you can scope any view to one site or roll up the fleet.
What is the multi-tenancy story?
There is none, deliberately. One core belongs to one customer, and RBAC inside the core is the isolation boundary. That removes an entire class of cross-tenant risk that a shared platform has to engineer around.
How do we get our data out?
It is already out — it lives in an open, standard columnar database you own and operate. Query it with standard SQL tooling, back it up with your existing tools, and keep it if you ever stop paying us. There is no export request and no proprietary format holding it.
Get started
Run it in your own cluster this week.
A 30-minute call, then an evaluation core on your infrastructure. You will see your own service map — built from your own traffic — before you decide anything.
No data leaves your environment, including during the trial