Most observability tools really kick into gear when something is already going wrong: latency spikes, a service stops responding, a metric breaches a threshold, and engineers begin reconstructing the root cause. Empirik wants to shift the decision-making point earlier. The startup, incubated by Sequoia Capital and founded by former IT leaders Avon Puri and Sudheer Dhurjati, has emerged from stealth with $21 million raised to build a platform that attempts to predict outages by observing changes before they cause a failure.
The idea stems from Puri’s experience, who, before joining Sequoia as chief digital and information officer, spent years working on infrastructure at companies like VMware and Rubrik. Together with Dhurjati, he hypothesized that modern models could understand relationships between configurations, dependencies, and changes better than systems based solely on static rules.
Almost every major incident has a backstory
An outage rarely appears out of nowhere. It can be preceded by a deployment, a configuration change, a dependency update, a shift in traffic, or a change in permissions. The problem is that in distributed architectures, these changes happen continuously, and their effects ripple across services owned by different teams.
Empirik builds a representation of these relationships and attempts to infer which changes could trigger cascading effects. If a component depends on another in a non-obvious way, the platform aims to flag it before the incident manifests.
From diagnosis to prevention
The AIOps sector has promised for years to use machine learning to correlate logs and alerts. The difference Empirik claims is focusing on the future rather than just the past. Not asking “why did the system go down?”, but “does this change risk bringing it down?”.
It is a massive distinction because the cost of stopping a risky deployment before production is far lower than the cost of recovering a service after an outage. But it requires a high level of accuracy: too many false positives would lead teams to ignore the warnings.
Modern infrastructure is difficult to understand even for those who built it
Microservices, APIs, queues, managed databases, and multi-region clouds create dependencies that no single person can keep entirely in their head. Documentation often lags behind the code. This makes incidents a knowledge problem as well as a technical one.
A system capable of reading configurations, change history, and telemetry can build a dynamic map that is more up to date than traditional architectural diagrams. The advantage of AI, if real, would lie precisely in its ability to reason across a massive volume of relationships.
Sequoia incubated the project from within
Empirik is unusual because its founders were working inside Sequoia before launching the company. The venture fund recognized that the problem could become a standalone business. This origin provides access to capital and a network of potential customers, but it does not guarantee the product.
The observability market is crowded with Datadog, Dynatrace, New Relic, Splunk, and numerous startups. Empirik must prove that prediction is not simply a feature that major vendors can quickly add.
Value is measured in minutes of downtime avoided
For a financial service, a marketplace, or a cloud platform, a few minutes of downtime can cost millions and damage reputations. This makes it relatively easy to justify software that prevents even a small fraction of major incidents.
The challenge is proving it. An avoided incident is, by definition, something that does not happen. Empirik will need to build credible metrics to show that an alert genuinely prevented a failure and was not merely a precautionary prediction.
AI can also create new outages
The same technology Empirik uses to prevent issues is entering development and operations workflows. Coding agents produce more changes, and operational agents can modify configurations automatically. As a result, the volume of changes could increase.
This makes it even more urgent to have controls that understand the impact of changes. If an agent can deploy code far faster than a human team, the verification system must be just as fast.
Trust requires explanations
A warning like “do not deploy this change” is not enough if the engineer does not understand why. To be useful, the platform must show the chain of dependencies and the factors that produced the prediction. Explainability here is not an academic requirement: it is essential for deciding whether to block a release.
The ability to indicate that “this service depends on this other database, which has already shown this pattern” can turn a probabilistic forecast into actionable guidance.
Prevention becomes the next goal of observability
For years, the industry has improved the speed at which companies discover and resolve incidents. Empirik is betting that the next competitive advantage will be preventing some of them from starting in the first place. Not all outages are predictable and external events will remain inevitable, but a significant share stems from internal changes.
If the startup succeeds in pinpointing that share with few false alarms, the 21 million raised could fund a new category. Otherwise, the product risks becoming just another source of alerts in already noisy systems. The difference between the two possibilities is measured by something very tangible: how many nights engineers will truly stop being woken up by a pager.
