Every engineering team has lived through the same story - an alert storm at 2 AM, dozens of notifications across Slack, PagerDuty, and Datadog, and a frantic search for what actually broke.
Traditional incident management tools were built for reaction, not understanding.
They show you symptoms - not stories.
At DevRev, we wanted to change that.
Our goal was to make incidents first-class citizens in the developer experience -not just logs or tickets - and to build a system that thinks in context: connecting infrastructure, code, and customer impact.
This is the foundation of DevRev’s Incident Management system.
1. A unified foundation: The DevRev graph
At the heart of DevRev lies the unified object graph -a shared representation of your entire product ecosystem.
Every concept in your universe - services, features, alerts, tickets, customers -exists as an entity in this graph, connected through typed relationships.
This design unifies what are usually disconnected worlds:
- The Dev world (code, commits, deployments)
- The Rev world (users, tickets, business outcomes)
When an incident occurs, this graph lets you reason both ways:
- Rootward: What broke, where, and why?
- Impactward: Who and what does it affect?
Because everything in DevRev ties into the same structured graph, incidents are no longer isolated objects- they’re contextual, connected, and traceable to both technical and business outcomes.
2. Listening to the system: From logs and alerts to signals
Incidents begin as whispers - a spike in latency, an anomaly in logs, or a user report that feels familiar.
DevRev’s Incident Management system ingests all these signals into a unified stream:
- Alerts from observability platforms
- Logs emitted from source code
- User or customer tickets that reference service issues
Each signal is normalized into a consistent DevRev object, retaining its metadata (service, scope, tags, timestamps).
Before any AI steps in, DevRev applies pattern mining and correlation heuristics -grouping related logs and alerts through identifiers like trace IDs, and when unavailable, through heuristic similarity (service, time window, and semantic similarity of messages).
The goal: turn fragmented alerts into structured clues.
3. Connecting the dots: AI-powered correlation
Once individual clues are gathered, DevRev’s correlation engine begins to reason.
Each alert or log cluster is passed through a large language model that has awareness of your system’s topology, metadata, and historical incidents.
It performs two levels of reasoning:
- Log ↔ Alert correlation: Determines if recurring log patterns are manifestations of existing alerts.
- Alert ↔ Alert correlation: Groups together alerts that likely describe the same underlying issue, using both structured data (trace ID, service, timestamps) and semantic context from natural language.
This stage transforms what would be dozens of independent alerts into a single, coherent incident candidate - a story arc beginning to form.
4. The judge: Deciding what’s real
High-signal systems generate noise transient failures, retries, partial outages.
That’s where the Judge comes in.
The Judge is an AI Agent built on DevRev’s Agent Platform.
It’s an LLM-powered classifier that determines whether a correlated cluster of signals represents a real incident worth human attention.
What gives the Judge its depth is context. It doesn’t just look at alerts; it considers:
- Graph relationships: which services, customers, and features are involved
- Observability metrics and code metadata
- Historical incident patterns and outcomes
- Business impact signals (from Rev data)
When the Judge declares a cluster real, DevRev promotes it to a first-class Incident object linked to its relevant Parts, owners, and historical traces.
If not, it’s quietly suppressed, avoiding unnecessary pages.
5. Ownership and routing: Context-aware assignment
Once an incident is created, the next challenge is ownership.
Instead of static on-call lists, DevRev uses the same graph to infer who should handle what - dynamically.
Ownership data isn’t hardcoded; it’s learned from recent commits, feature ownership, code paths, and past contributions.
When a new incident is confirmed, the system queries across this ownership graph - guided by the Search Agent, another modular AI running on DevRev’s Agent Platform.
The result: incidents are routed automatically to the most contextually relevant engineers, reducing the “alert ping-pong” that plagues traditional systems.
6. AI agents at work: DevRev’s modular intelligence
The Judge doesn’t work alone.
DevRev’s Agent Platform hosts a suite of extensible AI agents, each specializing in a layer of reasoning.
- Search agent: Traverses the DevRev graph to find relationships between services, features, and owners.
- Observability agent: Queries logs, metrics, and traces to surface root-cause evidence.
- Code agent: Connects incidents to code commits, deployments, and feature flags to highlight what changed.
These agents communicate using the Model Context Protocol (MCP), which lets them integrate with new connectors - from internal observability systems to custom data sources - without re-architecting the stack.
Together, they form a distributed reasoning system: agents with different specialties collaborating on the same problem - triaging, investigating, and validating incidents.
7. Collaboration and escalation: The human loop
Once ownership is clear, DevRev activates the workflow layer - paging, notifications, and escalation - all driven by context from the graph.
Policies can define retries, escalation paths, and multi-channel alerts (Slack, email, etc.), but the key difference is context continuity:
Every notification carries the full timeline -correlated alerts, code changes, customer impact - so whoever’s paged doesn’t start from zero.
By making incident response context-aware and collaborative by design, DevRev turns high-pressure firefighting into structured teamwork.
8. RCA and continuous learning
After mitigation, DevRev’s agents continue assisting with root cause analysis.
The Observability Agent aggregates metrics and logs; the Code Agent identifies recent changes; the Search Agent brings in business impact.
Because all of this lives on the same unified graph, RCA becomes a process of graph traversal rather than guesswork.
This tight integration of observability, ownership, and business context transforms incident management from a reactive process to a learning system.
9. The bigger picture
DevRev’s approach to incident management isn’t another tool bolted onto observability - it’s a rethinking of how teams understand failure.
By unifying logs, alerts, and code changes with customers, tickets, and features, it bridges the Dev–Rev divide - helping teams move from reaction to reasoning.
Because every incident, at its heart, is a story.
And stories deserve to be understood.
