Skip to content

Core Concepts

Hexcovery organizes everything it observes around one small, deliberate data model. Once it clicks, the whole product reads the same way — every page, every query, every link between things. This section explains that model.

The subject is software

Hexcovery watches software. Everything else — hosts, infrastructure, managed databases, message queues — exists to run software, and that is why we observe it too. But the software is the point.

On top of that subject, there are two gestures you actually perform as a human:

  • Decide. Read metrics across infrastructure, applications, and systems to make architecture decisions. "Is this service hot enough to split? Is that database the bottleneck?"
  • Blame. Spot an error or a criticality and trace it back to its cause. "This error you see here is caused by that piece over there that isn't working."

Almost everything in Hexcovery is in service of one of those two gestures.

Everything observed is an Entity

The fundamental unit is the Entity — a "piece" of your system. An Entity exists in its own right: it has a stable identity and its own dedicated screen where you can look at it alone, independent of anything it's grouped into.

An Entity is identity + the set of signals it currently has: traces, logs, cron heartbeats, OTLP metrics, host metrics. That signal set grows over time — a database first seen only through another service's traces can later gain its own metrics — but it stays the same Entity throughout.

→ Entities and signals

Entities are grouped into Projects

Entities are classified and grouped by a single OpenTelemetry attribute, service.namespace:

  • A Service is telemetry that carries a service.namespace — it has been attributed to a Project.
  • An External Service is a call-target seen with no service.namespace — a dependency (a database, a cache, an SMTP server) that belongs to no Project until it gains its own identity.
  • Infrastructure is the hosts and Kubernetes nodes your software runs on — the substrate.

A Project is a service.namespace. It collects and connects the entities that share that namespace to give you at-a-glance health and the "this error ← that piece" correlation — but it does not own them. The entities exist first; the Project is a lens over them.

→ Services, External Services, and Projects

Everything belongs to one Organization

All of your data lives inside a single Organization (your tenant). Every datapoint Hexcovery stores is tagged with your tenant, isolated from every other customer, and kept in the EU. Within the Organization you invite Users, group them into Teams, and assign roles.

→ Multi-tenancy: organizations, teams, and users

In one diagram

Organization (your tenant — owns all data + billing)
  └── Projects (= service.namespace)
        ├── Services           (entities WITH a namespace)
        ├── External Services  (call-targets WITHOUT a namespace — dependencies)
        └── Infrastructure     (hosts / k8s nodes — the substrate)

Every Service / External Service / host is an Entity:
  Entity = identity + { traces, metrics, logs, crons, host metrics }

Where this vocabulary shows up

These words are not just documentation — they are the navigation. The Services catalog and Projects pages are this model made clickable, and OQL lets you query any of it directly.