This deployment is our most frequently requested reference, so with the customer's permission — anonymised at their request — here is what actually happened, including the parts that did not go smoothly.
The starting position
A top-5 Indian private bank, roughly 900 managed units across core banking, payments, channel infrastructure, and supporting middleware. The NOC ran three shifts. Daily alert volume averaged 1,200. The night shift carried the same alert load as the day shift with 40% of the staffing.
The recurring pain was Oracle blocking sessions on the payments database. A long-running session would hold a row lock, transaction throughput would collapse, and the on-call DBA would be paged. Median time from first alert to resolution was 34 minutes, most of it spent getting a human awake, connected, and oriented.
Week one: observe mode
The platform was deployed with every policy forced to observe-only. It ingested telemetry, diagnosed incidents, matched policies, and recorded what it would have done — executing nothing. For seven days the bank compared the proposed actions against what its engineers actually did.
The 6% disagreement was the useful part. In most cases the platform proposed a correct but more conservative action than the engineer took. In eleven cases it had matched a policy that the DBA team considered inappropriate for that specific schema — which resulted in a scope narrowing on those policies before activation. That review is the reason the change advisory board approved activation at all.
Activation: deliberately narrow
The bank activated four policy classes, not the full library:
- Oracle blocking session termination, restricted to sessions exceeding a duration threshold with no in-flight commit, on a named list of schemas.
- Archive log space reclamation, gated on verified backup completion.
- Application service restart for a named set of stateless middleware services, with connection draining.
- Filesystem cleanup on a defined path allowlist, with age and pattern constraints.
Everything else remained observe-only or approve-then-act. This narrowness was the customer's call and, in hindsight, exactly right — it made the first month's results attributable rather than ambiguous.
The 2am event
Eleven days after activation, at 02:14, a batch job on the payments database opened a session that acquired a row lock and stalled. Within 40 seconds the platform had correlated the lock wait chain, identified the blocking session, verified against live state that it held no in-flight commit, confirmed it matched the approved schema list and duration threshold, captured session state for the audit record, and terminated it.
Transaction throughput recovered inside 90 seconds. The on-call DBA was notified, not paged. The morning review found a complete decision record: signals, diagnosis, policy matched, preconditions evaluated, action taken, outcome observed.
Results at 90 days
The 87% figure is against the activated classes, not against total incident volume — total estate autonomy at 90 days was 61%, rising as further classes were promoted. We think quoting the narrower number honestly is more useful than quoting a headline that requires a footnote.
What the bank did with the recovered time
Two night-shift engineers moved to problem management. In the following quarter they eliminated the root cause of the batch job behaviour that had been generating the blocking sessions in the first place — which is the outcome automation is supposed to enable and rarely gets credited for.
“We did not buy automation to reduce headcount. We bought it so the people we have stop spending their nights on things a script should have handled.”
Head of Infrastructure Operations, top-5 Indian private bank