Why Your Observability Needs an Ontology-Driven Knowledge Graph

An ontology-driven knowledge graph turns telemetry into operational context teams can actually act on.

01 THE PROBLEM

Observability debt is the failure mode where a team can collect plenty of telemetry yet still cannot explain a production issue fast enough to change the outcome.

The gap is not data volume. It is missing structure.

Most teams have logs in one tool, metrics in another, traces in a third, CI/CD events in a fourth, feature flags somewhere else, and ownership metadata trapped in GitHub, Terraform, Backstage, or somebody’s head. Every source is locally useful. None of them share a durable model of what a “service,” “user action,” “deployment,” “dependency,” “experiment,” or “customer impact” actually means.

That sounds academic until the first serious incident.

A checkout latency regression starts at 10:12. The on-call sees p95 spike in one dashboard. Another engineer sees elevated Kafka lag. Someone else notices a canary deployment finished nine minutes earlier. Product asks which customers are affected. Support asks whether this is isolated to one geography. Leadership asks if revenue is at risk. Nobody can answer from one place because the telemetry is connected by timestamps, not by meaning.

So the team does what nearly every team does: open twelve tabs, start a Slack war room, and reconstruct the system manually.

That is expensive even when it works.

Google’s SRE book treats reduction in mean time to detect and mean time to repair as a core reliability objective because outage duration compounds user harm and operational cost. DORA’s four key metrics likewise treat change lead time and time to restore service as first-order indicators of software delivery performance, not side concerns. If it takes 90 minutes to determine whether a deployment, upstream dependency, feature flag, or client release caused the problem, your observability stack is not helping where it matters most.

The real consequence is not merely slower incident response.

It is lower engineering throughput over time.

Staff and senior engineers become human join engines for fragmented data. Teams add bespoke dashboards because the shared ones cannot answer causal questions. Every incident produces another tribal runbook entry instead of better system understanding. As systems and teams grow, operational cognition does not scale with telemetry volume. It gets worse.

This is the point where dashboards stop being an asset and start being a tax.

An ontology-driven knowledge graph addresses that exact failure. It creates a typed, queryable model of entities and relationships across your software system so telemetry can be interpreted in context: this trace belongs to this user flow, which depends on these services, was modified by this deployment, owned by this team, behind this flag, and is now violating this SLO for these customers.

That is the difference between observing events and understanding the system.

02 WHY IT HAPPENS

The root cause is simple: most observability architectures are optimized for ingestion and search, not for system reasoning.

That was a rational choice.

The first generation of modern observability solved a real problem: infrastructure got distributed, logs exploded, and teams needed centralization. ELK stacks, metrics backends, and tracing systems gave engineers a way to see what happened across services instead of SSH-ing into boxes. Tools improved query speed, indexing, cardinality handling, and retention economics. Those are real wins.

But they mostly treated telemetry as records, not as knowledge.

A log line can tell you an API returned 500. A trace can show latency across spans. A deployment event can tell you version `2026.10.18.3` went live in `us-east-1`. What those systems usually do not encode as first-class objects is the meaning of the relationship between them:

• Which customer workflow did the failing call belong to?
• Which service dependencies form the blast radius path?
• Which flag state changed the code path?
• Which experiment cohort saw the regression?
• Which ownership boundary governs remediation?
• Which previous incidents look causally similar?

Without those relationships, the burden moves to humans.

Netflix has made this point directly in its work on ontology-driven observability: connectedness alone is insufficient; what matters is the explicit relationship between components, events, and system concepts across heterogeneous data. Their framing is useful because it names the missing layer clearly. Most observability stacks already have data pipelines. What they lack is a domain ontology that normalizes that data into concepts the business and engineering organization actually reason about.

This problem gets sharper for AI-first startups.

A 40-person product company in 2026 might have:

• managed Kubernetes or ECS
• Postgres plus a vector database
• event pipelines
• third-party model APIs
• internal inference services
• feature flags
• browser and mobile clients
• fine-tuning jobs
• retrieval pipelines
• background workers
• experiment frameworks
• cost and token observability

Each layer emits telemetry in a different format. The most important production questions cross those layers:

• Did a latency regression come from model routing, retrieval quality, cache churn, or a frontend release?
• Did answer quality fall for one tenant, one region, or one prompt template?
• Which incidents increase cloud cost without violating an infrastructure threshold?
• Which degraded user sessions correlate with a deployment and a prompt version change?

Traditional observability tools can surface pieces of that answer. They rarely assemble the answer.

There is also an incentive problem.

Infrastructure teams tend to own observability platforms. Product teams own user journeys. Data teams own analytics definitions. Security owns identity and asset inventory. Platform teams own service catalogs. Nobody is naturally chartered to create a shared semantic model across all of them.

So every function builds its own partial map.

That fragmentation is one reason service catalogs often stall. The catalog knows the names of services and owners but not how user-impacting behavior flows through them in production. Conversely, telemetry systems know the runtime behavior but not enough about product semantics and organizational ownership to make the behavior legible.

Stripe’s engineering culture has long emphasized strong internal abstractions and ownership boundaries as the company scaled complex payment flows. That pattern matters here. Reliability at scale is not only about seeing infrastructure metrics; it depends on durable models of systems and their contracts. Observability without explicit domain models eventually breaks because the company has more moving pieces than any one engineer can mentally join.

There is a final architectural reason this happens.

Most telemetry is append-only and event-shaped. But operational understanding is graph-shaped.

Entities persist over time. Their relationships change. A service depends on another service. A deployment modifies a service at a point in time. A feature flag gates a code path. A user session spans multiple calls. An experiment assigns a cohort. An incident affects a subset of tenants. A runbook belongs to a service-team pair. Those are not rows in one table. They are linked facts with temporal context.

That is why teams keep recreating graph logic in dashboards, notebooks, and ad hoc scripts. The shape of the problem keeps leaking through the tooling.

03 WHAT MOST GET WRONG

The most common mistake is to think better instrumentation alone solves this.

It does not.

You should absolutely improve instrumentation. Structured logs are better than free text. OpenTelemetry is better than bespoke formats. Trace propagation matters. High-cardinality dimensions matter when used carefully. But instrumentation quality only improves the fidelity of raw signals. It does not give those signals a shared operational meaning.

The second mistake is to call a CMDB or service catalog “the knowledge graph.”

That also fails.

A static inventory of services, owners, repositories, and cloud resources is useful. Backstage, for example, can greatly improve discoverability and ownership hygiene. But a catalog is not enough if it does not link to runtime events, customer journeys, deploy history, experiment state, and inferred causal patterns. Otherwise it helps you answer “who owns this service?” but not “why did checkout for German iOS users degrade 14 minutes after a config push?”

The third mistake is trying to brute-force the problem with dashboards.

This is the standard local optimum.

Every team creates “golden dashboards.” Then they create service dashboards, customer dashboards, deployment dashboards, and exec dashboards. Incidents still require hand-joining facts across them because each dashboard is a projection of one data source or one team’s mental model. It is not a system model.

Charity Majors has argued for years that observability is about understanding unknown-unknowns, not just watching known metrics. Her critique applies here. Dashboard-heavy approaches tend to optimize for predefined views. They help when the failure matches the dashboard designer’s assumptions. They fail when the issue crosses boundaries the dashboards were never designed to connect.

The fourth mistake is overbuilding too early.

A startup with 20 engineers does not need to emulate Netflix. Building a full RDF stack, custom ontology engine, temporal graph store, and inference pipeline before your deployment process is stable is engineering theater. You can create as much semantic overhead as you remove if the ontology is too abstract, too broad, or disconnected from incident response.

The cost of getting this wrong is real.

Uber’s 2019 postmortem on its major outage described cascading failures tied to configuration and infrastructure interactions across systems. Whether or not a knowledge graph would have prevented the outage, the pattern is familiar: failures spread faster than humans can integrate fragmented system context. Large-scale incidents routinely expose the same operational weakness. Teams have local telemetry and still lack a globally consistent model of the state change that mattered.

Knight Capital’s 2012 disaster is an even harsher example of missing deployment and runtime coherence. The firm lost hundreds of millions of dollars after defective software was deployed unevenly across servers. The headline cause was a bad release process, not “poor observability,” but the broader lesson stands: when system state, rollout state, and business impact are not modeled together, teams discover reality through loss.

The fifth mistake is buying one more observability vendor and expecting semantics to emerge automatically.

Vendors can help a lot with ingestion, correlation, and incident UX. Datadog, Honeycomb, Grafana, and others have pushed the market forward meaningfully. But no vendor can infer your company’s operational ontology without deliberate work from your side. The semantics that matter most are specific to your business:

• what counts as a user session
• what defines a degraded answer for your AI product
• what a successful onboarding flow is
• how flag states map to customer entitlements
• what blast radius dimensions leadership cares about

Those definitions are strategic assets. If you do not encode them explicitly, the tool cannot reason with them.

04 THE FRAMEWORK

The workable approach is not “build a giant graph.” It is: define the smallest useful ontology that answers your highest-cost operational questions, then grow it incident by incident.

That is the pattern that tends to hold up.

1. Start with operational questions, not data sources

Begin with the five to ten questions that currently take your best engineers too long to answer.

Good examples:

1. What changed in the 30 minutes before this SLO violation?
2. Which customer journeys are affected by this service regression?
3. Which dependencies sit on the critical path for checkout or inference?
4. Which deployments, flags, or experiments correlate with a latency spike?
5. Which team owns remediation, and what runbook applies?
6. Has this causal pattern happened before?

If you cannot name the questions, your ontology will drift into taxonomy work.

Use incident reviews as source material. Take the last five sev-1 or sev-2 incidents and list the joins humans had to make manually. Those joins define your first graph edges.

For most Series A–C startups, the first useful ontology is surprisingly small. It usually starts with 8–15 entity types:

• service
• endpoint or operation
• deployment
• repository
• team
• on-call rotation
• feature flag
• dependency
• customer or tenant
• user session
• SLO
• incident
• experiment
• model or prompt version
• region

And 15–30 relationship types:

• `owns`
• `depends_on`
• `deployed_to`
• `gates`
• `violates`
• `affects`
• `belongs_to`
• `calls`
• `triggered`
• `correlates_with`
• `routes_to`

That is enough to be useful.

2. Separate the ontology from the storage choice

This is where many efforts get derailed.

An ontology is the meaning layer: the types, properties, and relationships you assert about your system.

A knowledge graph is one implementation pattern for storing and querying those assertions.

Do not bind these decisions too early. You can model the ontology in a simple schema registry, protobufs, JSON-LD, or even relational tables with explicit edges before committing to a dedicated graph database. The critical thing is consistency of meaning across ingestion paths.

The practical question is not “Should we use Neo4j, Neptune, JanusGraph, or Postgres?” The practical question is “Can we represent and query typed entities and time-bounded relationships cheaply enough to support incident response?”

For a sub-100-engineer org, Postgres with well-designed edge tables and materialized views is often enough for the first year. If your main need is incident correlation and dependency traversal over tens of millions of edges rather than billions, a relational core is simpler to operate and easier for internal tooling teams to extend.

Move to a specialized graph approach when one of three things becomes true:

• traversals are operationally central and too slow in SQL
• schema evolution across domains becomes painful
• you need graph-native inference patterns at a scale SQL no longer handles cleanly

That sequencing matters. Premature graph infrastructure is one of the easiest ways to lose a year.

3. Normalize events into typed facts

This is the ingestion discipline that makes the system real.

Every raw event that enters your observability estate should either map to an existing entity or create one, and it should assert typed facts about relationships.

Examples:

• A CI/CD event creates a `Deployment` entity linked to `Service`, `Environment`, `Commit`, and `Team`.
• A feature flag change creates a `FlagStateChange` entity linked to `Flag`, `Environment`, `Actor`, and affected `Service`.
• A trace span maps to `Operation` and `UserSession`, linked by `invokes` and `part_of`.
• An incident links to violating `SLO`, suspected `Deployment`, affected `TenantSegment`, and responsible `Team`.
• A model router decision links `Request` to `ModelVersion`, `PromptTemplate`, `RetrievalIndex`, and `CostProfile`.

Netflix’s public discussion of ontology-driven observability highlights this normalization step directly: heterogeneous telemetry becomes useful when translated into shared domain concepts such as user session, API call, deployment event, experimentation, and quality-of-experience regression. That principle generalizes well beyond Netflix.

The rule to enforce: every producer can emit custom fields, but only platform-owned mappings can define canonical entity and relationship types.

That preserves team autonomy while preventing ontology drift.

4. Make time a first-class dimension

Most observability systems are temporal by nature. Most internal knowledge models are not. That mismatch causes endless confusion.

Relationships change.

A service owner changes. A dependency is added. A flag gates traffic for one week and is then removed. A deployment is active between two timestamps. A prompt version only serves one tenant cohort for four hours. If your graph cannot answer “what was true at 10:12 when the regression started?” it will fail during incidents.

Netflix has described snapshotting graph state at regression time to compare healthy versus degraded states. That is exactly the right instinct. You need temporal joins, not just current truth.

At minimum, every edge that can change should include:

• `valid_from`
• `valid_to`
• source of truth
• confidence or assertion type if inferred

This is not optional. Half of root-cause confusion comes from asking today’s metadata to explain yesterday’s failure.

5. Tie the graph to SLOs and business-critical flows

If the ontology never meets your reliability objectives, it becomes an expensive side project.

Map graph entities to service level indicators and user journeys.

The Google SRE book recommends setting availability targets based on user experience and error budgets rather than purely internal metrics. Use that logic here. Your graph should answer questions in the shape of user impact:

• Which SLOs are currently violated?
• Which user journeys traverse the violating services?
• Which tenants or cohorts are affected?
• Which recent changes intersect the path?

For example:

• `CheckoutJourney -> depends_on -> PaymentOrchestrator`
• `PaymentOrchestrator -> calls -> FraudDecisionAPI`
• `Deployment-1234 -> modifies -> FraudDecisionAPI`
• `SLO-CheckoutLatency -> violated_by -> CheckoutJourney`
• `TenantSegment-EU -> affected_by -> SLO-CheckoutLatency`

Now your incident tooling can say something better than “fraud service latency is up.” It can say: “A deployment to FraudDecisionAPI 11 minutes ago intersects the critical path of checkout and correlates with p95 checkout latency violations for EU tenants.”

That is an operationally actionable sentence.

6. Instrument ownership and remediation paths, not just topology

Topology helps you understand where. Ownership helps you act.

At a minimum, connect these entities:

• service → owning team
• service → on-call rotation
• service → runbook
• service → repo
• service → deploy pipeline
• incident type → remediation pattern

GitHub Engineering, Cloudflare, and Shopify have all published extensively about internal platform investments that reduce coordination overhead by making ownership and deployment mechanics explicit. The common pattern is this: reliability improves when the path from detection to action is shortened structurally, not heroically.

An ontology-driven graph should let your incident tooling route work automatically:

• page the correct team
• attach the correct runbook
• show the last three similar incidents
• highlight the most likely related changes
• identify dependent services and customer impact

This is the practical threshold for usefulness. If the graph does not reduce coordination latency, it is not earning its keep.

7. Add inference only after your base facts are trustworthy

Inference is powerful and easy to abuse.

Once you have reliable base facts, you can derive higher-order insights:

• probable blast radius
• likely root-cause candidates
• recurrent causal motifs
• chronic dependency hotspots
• hidden single-team bottlenecks
• cost anomalies linked to product changes

But inferred edges should be clearly marked as inferred, with confidence levels and supporting evidence. Do not blur them with asserted facts.

This matters for trust.

Engineers will abandon the system the first time it confidently points to the wrong deploy because correlation was mistaken for cause. Better a modest graph engineers trust than an “intelligent” one they ignore.

A practical benchmark: do not add automated causal ranking until your ingestion coverage includes at least 90% of production deployments, 95% of services with clear ownership metadata, and trace or event linkage for your top three user journeys. Those numbers are practitioner thresholds, not industry standards, but they are the rough point at which suggestions stop being mostly noise.

8. Treat ontology governance like API governance

The ontology is a product. Run it like one.

That means:

• a small owner group, usually platform plus one or two senior engineers from product-heavy domains
• versioned schema changes
• compatibility rules
• clear canonical definitions
• deprecation paths
• docs with examples from real incidents

Do not let every team mint its own “session,” “customer,” or “latency event” type.

This is exactly the same failure mode as undisciplined API design. Local convenience creates global confusion.

A useful operating model is monthly ontology review with hard criteria:

• Did this new type answer a recurring operational question?
• Can existing types represent it?
• Which systems will produce it?
• Which teams will consume it?
• What breaks if the definition changes?

If the answer to those is fuzzy, delay it.

9. Measure whether the graph reduces operational toil

This is where many internal platform efforts fail. They get built but never judged against outcomes.

Track:

• mean time to identify likely root cause
• mean time to route to the right owner
• mean time to restore service
• number of tools/tabs opened during incident triage
• percentage of sev incidents where deployment, flag, and ownership context was auto-attached
• percentage of postmortems requiring manual timeline reconstruction

Use DORA’s “time to restore service” as one hard anchor. If your graph project does not improve restoration time for material incidents within two quarters, the scope is wrong.

A concrete target for a mid-stage startup: reduce time-to-owner assignment for sev-2 incidents to under 5 minutes and reduce time-to-first-plausible-change-candidate to under 10 minutes within 90 days of rollout. Those are operationally meaningful thresholds and realistic with modest scope.

10. Keep the first use case painfully narrow

The best first use case is usually one of these:

• deployment correlation for one critical path
• feature flag impact on one revenue-critical workflow
• incident impact mapping for one product surface
• AI inference quality regression tracing for one model-serving path

Do not start with “enterprise-wide observability ontology.”

Start with “checkout incidents currently take 45 minutes to connect to likely changes, and we will get that below 10.”

Linear is a good reference point culturally, even if not specifically for ontology work. The company is known for narrowing scope ruthlessly and building tools around speed and operational sharpness instead of broad platform ambition. That mindset fits here. You are not designing the perfect knowledge representation of your company. You are removing high-cost ambiguity from operational decisions.

05 STRATEGIC TAKEAWAY

An ontology-driven knowledge graph is not an observability upgrade. It is a decision-speed upgrade. If you apply it well, incident response shifts from manual correlation to system-assisted reasoning, and reliability work starts compounding instead of resetting every quarter. If you do not, your best engineers remain the semantic layer between disconnected tools, and every increase in architecture complexity slows the company exactly where a CTO feels it most: slower recovery, noisier ownership, and lower confidence shipping changes into critical paths.

06 IMPLEMENTATION ANGLE

If you were starting this quarter, do not buy a “knowledge graph initiative.” Stand up a small cross-functional working group: one staff engineer from platform, one senior engineer from a revenue-critical product area, and one person who owns incident management or SRE practice. Give them 45 days to model one critical workflow end to end: entities, relationships, data producers, and the three incident questions that must become one-click answerable. How Nearshore Engineers Supercharge AI Startup Velocity

Technically, use what you already have first. OpenTelemetry for spans and resource metadata. CI/CD webhooks for deployments. Feature flag events from LaunchDarkly, Statsig, or your internal system. Ownership metadata from Backstage, GitHub CODEOWNERS, PagerDuty, or Terraform. Store canonical entities and edges in a system your platform team can operate comfortably today—often Postgres plus a lightweight service layer. Only introduce a graph-native store when traversal or inference becomes a measured bottleneck, not a theoretical one.

The team pattern matters as much as the tooling. Ontology work fails when it sits only with infra because the most valuable entities are often product concepts: user session, workspace, tenant, workflow success, inference quality, experiment cohort. If your company is growing fast, this is also one of those areas where leadership support matters because someone has to force canonical definitions across teams. Amplify helps engineering teams scale, but the underlying lesson applies regardless of partner: operational clarity comes from shared system models, not from adding another dashboard.

07 FAQ

Q: What is an ontology-driven knowledge graph in observability? A: An ontology-driven knowledge graph in observability is a system that models operational entities—such as services, deployments, user sessions, feature flags, teams, and incidents—and their typed relationships so telemetry can be reasoned about in context. Netflix’s work on ontology-driven observability describes this as normalizing heterogeneous signals into shared concepts like “user session,” “API call,” and “deployment event,” which then support end-to-end incident analysis. Q: How is a knowledge graph different from a service catalog like Backstage? A: A service catalog like Backstage is primarily an inventory and ownership system: it tells you what services exist, who owns them, and where code lives. A knowledge graph goes further by connecting catalog entities to runtime facts such as traces, deployments, SLO violations, feature flag changes, and customer impact, which lets teams answer operational questions like “which deployment likely caused this checkout regression?” rather than only “who owns this service?” Q: When does a startup actually need ontology-driven observability? A: A startup needs it when incidents routinely require manual joins across multiple tools and the delay affects recovery or shipping confidence. In practice, that often appears between 30 and 100 engineers, when teams have several production services, feature flags, CI/CD automation, and at least one revenue-critical workflow where time to restore service materially matters under DORA metrics. Q: Do you need a graph database to build ontology-driven observability? A: No. Most teams should not start with a graph database. For an early implementation, Postgres or another relational system can store canonical entities and edge tables effectively, especially when the initial goal is deployment correlation or incident routing rather than large-scale graph inference. Move to a graph-native store only when traversals, schema evolution, or temporal reasoning become measured bottlenecks. Q: What is the fastest first use case for an observability knowledge graph? A: The fastest first use case is usually deployment and feature-flag correlation for one critical user journey, such as checkout, signup, or model inference. That scope is narrow enough to implement in 30–60 days and valuable enough to improve time to restore service, which DORA tracks as one of the four core software delivery metrics.