100% platform availability and ML-driven anomaly detection: How a leading Indian bank runs Elastic Observability for 50 million customers

One of India's largest private-sector banks moved its AIOps practice onto an on-premises Elastic Observability deployment, replacing static alert thresholds with ML-driven anomaly detection and holding the same telemetry retention on up to 30% fewer servers.

A leading private-sector bank in India runs an AIOps practice that has to keep a heterogeneous distributed and on-premises estate healthy for 50 million retail and corporate banking customers. Before, engineers could see individual fail points but not their business impact — and finding and fixing root cause across siloed dashboards and static thresholds was slow and draining. The bank standardized on Elastic Observability, using ML-driven anomaly detection with confidence scores, custom forecasting and load-characterization models, and hot, warm, and frozen data tiers. Static thresholds gave way to dynamic detection, root cause now surfaces in near real time, and the same telemetry retention runs on fewer servers at close to 100% availability. Here's how.

A leading Indian private bank serving 50 million customers runs its observability practice on an on-premises Elastic Observability deployment that holds the same telemetry retention on up to 30% fewer servers. The estate is heterogeneous and distributed by design: Retail and corporate banking systems are spread across multiple locations in India, some on premises and some in cloud environments, with each application surrounded by many supporting components.

That shape is what makes observability hard. In a system that is heterogeneous in nature and distributed, getting the underlying details in near real time is difficult, and monitoring tools that give native visibility into one system at a time cannot deliver discovery horizontally across all of them.

So, the bank’s AIOps unit set out to close that gap. The operating-model shift that followed was as much about people as about tooling: moving the team off manual, high-skill firefighting and onto ML-assisted detection where the platform points to the problem and the engineer makes the call.

The AIOps practice drew a clear line between monitoring and observability. Siloed monitoring products gave native visibility aligned to a single system, while observability provided full discovery horizontally, across every system that sits behind a customer-facing application. For a bank running a mix of on-premises and cloud systems across many locations, that horizontal view was necessary, not a nice-to-have.

When the team evaluated observability platforms, three requirements guided their final decision: speed, integration capability, and the ability to scale with load introduced over time. Observability is never about integrating one system. There are many components surrounding each application, so tool selection has to assume growth. A platform sized for today has to hold up when load increases six months, a year, or a couple of years later, and that scaling has to be designed in from the start.

Elastic met these requirements in both its open source and enterprise forms, and the team's own adoption pattern mirrored a broader trend: engineers begin with Elastic’s community edition quickly because it is easy to start and they’re well supported — then they move to the Enterprise subscription once they have verified the potential benefits. The Enterprise capabilities that mattered here were concrete: hot, warm, and frozen nodes for infrastructure savings, managed shards so the team does not have to manually manage them, easier maintenance, and greater stability at scale.

Before this approach, a fail point in an individual application or component could be identified, but its impact was very difficult to pinpoint. Because issue identification took time, recovery took time — and fixing the underlying cause was slow once the problem was finally understood.

The cost landed on the team as fatigue. Their work was skill-driven, so when a problem hit, someone had to find the right person to fix the underlying issue before anything could move. Detection depended on static thresholds: If a metric crossed a fixed limit, someone went to investigate. But the world is dynamic. Data, interfaces, and load all change, and load varies by weekday and by season, so fixed limits either fired on normal variation or missed real problems.

Without a horizontal view, monitoring stayed siloed. Teams integrated many data sources, built many dashboards, and invested in large monitoring displays, watching each layer separately. The team's time went to identifying issues, troubleshooting, and communicating status to business stakeholders, rather than to fixing root cause.

The bank’s Elastic deployment is on-premises. Telemetry flows from a heterogeneous set of sources into Elasticsearch and is analyzed with Elastic's machine learning, which surfaces anomalies for engineers to investigate. For this bank, Elastic's integration surface was a significant deciding factor, given the platform consumes not only SNMP traps and syslog but many other types of data sources. With Elastic’s 450+ out-of-the-box integrations, these can be ingested and customized without building each connector from scratch.

Elastic data storage is tiered. Rather than building servers out horizontally with no index lifecycle management (ILM), the bank moves data through hot, warm, and frozen tiers. Recent data sits in hot nodes for fast retrieval, older data moves to warm, and the longest-retained data lands in the frozen tier. Retrieval from frozen is slightly slower, but an issue from 90 days or six months ago can still be investigated with searchable snapshots without the need for rehydration or incurring the cost of live data.

The Elastic deployment scales to 1,000+ servers supporting banking functions for 50 million customers across retail and corporate banking, spread across multiple locations in India.

• On-premises Elastic Observability deployment (Enterprise subscription)
• Ingest from heterogeneous sources: SNMP traps, syslog, and additional formats
• Elasticsearch store with hot, warm, and frozen data tiers
• Managed shards; no hand-managed shard allocation
• ML anomaly detection on ingested metric data, with confidence scores per KPI
• Custom ML models for forecasting and load characterization
• Alert optimization to reduce volume across sources
• Logs, metrics, and application performance data correlated for near-real-time root cause
• Kibana as the investigation and dashboard surface
• Retention target of 90 days across tiers

Anomaly detection with confidence scores

Static thresholds cannot keep up with a dynamic estate, so the bank replaced them with ML-driven anomaly detection. The platform ingests metric data per KPI, learns the pattern, and when a value deviates from the trend it calls out that KPI for the given time window with a confidence score. The confidence score tells an engineer how sure the model is about the symptom, so attention goes to real deviations rather than to every crossing of a fixed line.

At the bank's scale, that turns anomaly detection from a manual exercise into a configurable one, where models run against the incoming data for relevancy and the team can act quickly.

Custom ML: Forecasting, load characterization, and alert optimization

Alongside the out-of-the-box detection, the team builds its own models. Forecasting projects a KPI forward, for the next half hour, for instance, which supports capacity planning and draws attention to systems that need to be watched or fixed before they fail.

Load characterization models how response time and error rate change as load rises, so abnormal behavior under load is picked up against a learned baseline rather than a guess. Alert optimization looks across the alerts arriving from many sources and reduces them to keep volume minimal.

In this way, the team's framing has been deliberate: Use out-of-the-box capability first and customize only where there is no other way. For their needs, custom development is not ideal as it means less standardization as people and requirements change.

Tiered storage: Long-term retention without an inflated server bill

The hot, warm, and frozen model is what lets the bank hold long-term retention affordably. On a community-style flat build, servers scale out horizontally with no tiering; on the Enterprise subscription, data lifecycles through the tiers so the team manages fewer servers for the same retention. That matters beyond the hardware line: Every server carries recurring operational cost, because each one has to be patched, vulnerability-baselined, and maintained. Fewer servers means a smaller surface to secure and maintain, while near-real-time investigation and long historical retention is fully preserved.

Logs, metrics, and application performance in one picture

The bank’s AIOps team treats logs as the source of truth for the symptom and health of the ecosystem, while application performance monitoring shows them what is happening at execution time. Combining application performance data, metrics, and logs in one near-real-time view gives teams a complete picture and lets engineers spend less time troubleshooting because they can find exactly where the problem is. From there they can enable workflow-based responses, for example, when one server in a farm crosses a threshold.

The measurement loop is human-owned. Because anomaly detection returns a confidence score, engineers can mark results with thumbs up or thumbs down, and that feedback retrains the model toward a better confidence score over time. That same loop changes who can operate the system. As AI capability enters the workflow, high-skill work shifts toward a lower-skill profile assisted by the model: The platform becomes an extended team member, and validation and measurement remain easy because a person is still in the loop making the judgment call.

With the platform in place, a day on the AIOps desk looks different. Instead of watching many siloed dashboards for a static limit to trip, the team lets ML surface a deviation on a specific KPI with a confidence score. From there the engineer pinpoints the problematic layer, calls the owner who can fix it, and, because the underlying problem and its impact are already understood, communicates cleanly to business stakeholders about what is affected and what is being done. The judgment call still belongs to the engineer; what changed is that the platform hands them a located, scored problem instead of a wall of alerts to triage.

Without this observability solution, the team knows what they would be facing: frequent issues, and a lot of time spent identifying them, alongside troubleshooting and managing stakeholder communication. With Elastic, they can achieve consistent availability, including at peak load, and that consistency is what the observability practice is built to hold.

The results the bank already sees — root cause in near real time, long retention on fewer servers, and platform availability close to 100% — across a distributed, heterogeneous estate serving 50 million customers, set the direction for what it wants next.

The AIOps roadmap for the bank is largely an engineering effort. The team wants to push more of the custom solutions it has built, and the custom work other organizations build, into standardized, out-of-the-box patterns, so adoption is faster and the cost to build and maintain drops. It also wants richer contextualization: Metric ingestion happens per KPI today, but aggregating and contextualizing those KPIs by layer, so a network-specific view shows a network team its own impact and dashboards, would make both operators' and developers' work closer to plug and play.

Standardization is the throughline, because custom development is where consistency erodes as developers, training, and users change over time.

Your organization may not be monitoring an estate that serves 50 million customers today, but the same principles apply whether you are standardizing your first observability deployment or scaling to a distributed, heterogeneous estate: full-fidelity telemetry in one store, dynamic ML detection instead of static thresholds, agentic investigations and remediation, and tiered retention that keeps history affordable without giving up investigation depth.

See how Elastic Observability replaces static thresholds with ML-driven anomaly detection across logs, metrics, and application performance data, or start now with a free trial.