The CTO asked which Digitate AIOps India deployment we should buy. That is not actually the question. The question is which on-call pattern you want to keep paying for, and which one you want to make the software’s problem.

I walked into the firm’s Andheri East office on a Monday morning convinced this was an observability problem. Three calls and one weekend of log reading later, I had a different answer. AIOps for this team was not about prettier dashboards. It was about whether the Sunday-night batch could fix itself before the engineer on rota got to his second cup of chai.

The Sunday that triggered the call

The firm runs a SaaS reconciliation platform used by mid-sized payments processors across South East Asia. Their largest client, an Indonesian wallet provider, runs a settlement file every Sunday at 22:00 IST. The file flows through 14 batch jobs in order, lands in a Postgres warehouse, and triggers a Power BI refresh that the client’s CFO sees first thing Monday morning Jakarta time.

For three Sundays in a row, job 9 in that chain (a reconciliation merge against the previous week’s holdings table) had silently failed. Silent in the sense that the job exited with code 0 but wrote zero rows. The downstream report rendered with last week’s numbers. The Indonesian CFO noticed on the second Monday. By the third Sunday, the conversation had escalated to a credit on the next invoice and a “we need to see your run-book by Friday” email.

The on-call engineer, Anish, had been on the rota for all three Sundays. He had restarted the job each time and pasted the same root-cause note into ServiceNow three times: “Suspected deadlock on holdings_wk table. Recommend long-term review.” The long-term review had not happened. There were nine other things on his queue and one of him.

Why I came in thinking observability, and why I left thinking automation

The firm already had Datadog APM on the application tier and a basic Prometheus + Grafana stack on the database. The dashboards were fine. The dashboards had, in fact, shown the deadlock pattern correctly all three Sundays. The dashboards did not call Anish. Anish was asleep.

That is the part the observability vendors gloss over. A dashboard describes a problem. It is not a fix. MTTR for this failure class was 71 minutes on average, and 68 of those were “Anish wakes up, reads the alert, SSHs to the jump host, finds the right log, recognises the pattern, restarts the job.” The remaining 3 minutes were the actual restart.

If you are paying 68 minutes of senior engineer time on a Sunday night for a known pattern with a known fix, the right tool is not a better dashboard. It is something that can do the fix itself, log it for audit, and only escalate when it sees something new. So we ran a six-week pilot.

The shortlist, the math, and how Digitate AIOps India earned the spot

We looked at three platforms in detail. The shortlist mattered: the CTO had been pitched ServiceNow ITOM by his rep two weeks earlier and was leaning that way for renewal-bundling reasons. The engineering lead was leaning Dynatrace from her previous firm. I was skeptical of the whole category.

Here is the honest comparison we put on the table. Seat counts move every quarter; this is the architecture call.

Three observations from that table. Dynatrace would have told Anish faster. It would not have restarted the job. That is a real distinction. ServiceNow ITOM is the right answer if your operations centre already lives inside ServiceNow; this firm did not. ignio is the only one of the three whose product story starts with closed-loop automation rather than treating it as an integration. For a small ops team running a known, repeatable batch with known failure modes, the third option does the most work per rupee.

What the six-week pilot actually looked like

We ran the pilot on the Sunday batch chain and on one ERP-adjacent invoice job raising similar tickets. ignio’s pattern library covered both out of the box. I had assumed three weeks of tuning. We spent four days tuning and the rest of the time watching.

Week one. Baseline. ignio in observe-only mode. The Sunday batch failed at job 9 again. ignio logged the pattern, mapped it to two prior signatures from the integration scan, and noted what it would have done: kill the orphan transaction on holdings_wk, restart job 9, re-trigger the three downstream jobs in dependency order. Anish, woken up, did exactly that. 64 minutes.

Week three. ignio in act mode for that specific pattern, with a 60-second confirm window. The job failed at 23:47. ignio acted at 23:48. The dependent chain restarted clean by 23:56. The Power BI refresh ran at 02:30 IST as scheduled. Anish got an FYI ticket and slept through it. The Indonesian CFO’s Monday morning report rendered with the correct numbers for the first time in four weeks.

Week six. MTTR for that failure class was nine minutes, eight of which were the dependent-job re-run that runs at the speed it runs. The rota stopped getting Sunday pages for batch deadlocks. They got two pages that month for genuinely new failure patterns. The team is now spending its attention on the unknowns, not the knowns.

The trade-offs we made honestly

Three things the marketing deck does not say loudly enough.

First, ignio is not a deep APM. If the firm later needs distributed tracing at a call-stack level, they add a tracer or live with what Datadog gives them. The team’s pain was not “we cannot see what the code is doing”, it was “we cannot get the batch to fix itself”.

Second, the value of an AIOps platform compounds with the known-pattern library. The first month was hand-holding. By month three, ignio was acting on failure classes we had not anticipated. If the team stops feeding the system, the curve flattens.

Third, automation acting on production needs governance. We wrote a one-page change-control note covering what ignio is allowed to do without confirmation, what needs human acknowledgement, and what is escalation-only. The auditor wanted to see this. Have it written before act-mode goes on.

What this looks like on the architecture diagram

The existing Datadog + Prometheus + Grafana set-up stays. The observability layer feeds ignio. ignio sits one layer above as the orchestration brain, talks to ServiceNow for ticketing, talks to the database tier and batch scheduler for action, talks to Azure for self-healing on the VM side. The Sunday batch chain, the invoice job, and two file-movement workflows are in act-mode. Everything else is in observe-mode. We added an ISO 27001 control mapping for the act-mode rules so the auditor could trace each action back to a policy.

The team’s Sunday rota is one engineer instead of two. The engineer reads the FYI ticket on Monday morning over chai instead of fixing it on Sunday night.

FAQ

Is ignio AIOps an Indian product?

Digitate is a software venture of TCS. ignio launched in 2015 and runs as SaaS on Azure with India region availability. India-built and India-hostable. For BFSI estates governed by RBI residency clauses, that matters.

How does ignio AIOps differ from a SIEM or an EDR?

SIEM and EDR watch for security events. AIOps watches for operational events in your IT estate. ignio’s closed-loop automation will then restart, route, or remediate. The two categories complement each other; not substitutes. Pair ignio with Sequretek XDR or Seceon aiSIEM if you want both.

What size of team does this start to make sense for?

Anywhere from 6 engineers and up if those engineers carry an on-call rota with repeating failure modes. Below that you can probably script the patterns yourself. Above 20, the platform pays for itself in night-shift hours within a quarter.

What about audit and residency?

Every automated action ignio takes is logged with the rule that fired it. Useful for DPDP audit trails and CERT-In incident-reporting needs. Pair the audit log with the DPDP compliance package. See the parent page on Digitate ignio AIOps in India.

P.S. Karthik here. We shipped a similar setup for a Bengaluru fintech two months ago. They asked the same question you are probably asking: how do we know what the platform actually changed last night? ignio writes the action and the rule that fired it to the same audit log your SIEM reads. We pulled six weeks of that log for their RBI inspection in week eight; the inspector spent eleven minutes on it and moved on. One thing to watch: the per-resource billing on Azure shifts at the next renewal window. Lock that in writing before you sign.