At Ardent, we believe the reliability of a data operation is often decided in the moments closest toaction:when an issue is detected, interpreted, escalated and resolved.

In this article, we focus on three areas within SRE where those moments happen most often: runbooks, incident management and alert triage. These key areas shape how teams respond to known problems, how quickly live issues are understood, and whether engineers see the right signals early enough to protect client delivery.

That can mean choosing the safest recovery path when a pipeline fails, understanding whether a delayed report is linked to an upstream data issue, or filtering a noisy alert queue without missing the signal that points to real business risk.

Runbooks, incident management and alert triage give structure to those decisions. They help teams move from uncertainty to action in a controlled, repeatable way, making them essential to reliable data operations.

Our aim is to show how AI can strengthen these specific parts of SRE: not by replacing engineering judgement, but by adding context, speed and consistency to the operational decisions that keep data environments reliable.

To examine these areas in more depth, we spoke with two of Ardent’s technical specialists: Laxman Amrale, Lead Data Architect, and Shoaib Mulani, SRE and AI Lead. Their work sits at the intersection of data architecture, reliability engineering and AI-enabled operations, giving them direct insight into the pressures these processes are designed tomanageand the opportunities AI creates when introduced into SRE in a controlled, practical way.

Runbooks are becoming living decision-support tools

Runbooks turn operational knowledge into repeatable action: what to check, what to rule out, what is safe to do and when to escalate.

That structure matters when client delivery is at risk. A delayed report, failed pipeline or incomplete data output needs a response that is fast, consistent and controlled. The challenge is that runbooks can become static documents in environments that are constantly changing. Data pipelines evolve, dependencies shift and engineers discover better ways to resolve incidents, but unless those learnings are captured, the runbook becomes less useful over time.

This is where AI can improve the SRE process. It can turn the traditional runbook from a static reference document into a more dynamic decision-support tool. Instead of an engineer manually searching through logs, dashboards, previous incidents and documentation, AI can surface the most relevant guidance in the moment.

In Ardent’s environment, that could mean analysing Databricks logs, job runtimes, upstream dependencies and historical incident patterns, then pointing the engineer towards the runbooksection most likely to apply. With Genie, Databricks’ AI assistant, already supporting deeper log analysis, this becomes a natural extension of how engineers investigate issues.

AI can also help keep runbooks accurate. One of the most practical opportunities identified in our discussion with Laxman and Shoaib is the ability to compare documented steps with the actions engineersactually tookduring an incident. If a team skipped a step, added a new check, escalated earlier than expected or used a different resolution path, AI can flag where the runbook may need updating.

It can also turn PagerDuty call notes, Slack threads and incident summaries into draft improvements. The engineer still reviews and approves the change, but the burden of capturing the first version is reduced. That matters because good SRE is not just about resolving the incident in front of you. It is about making sure the next response is faster, safer and better informed.

The safeguard is clear: AI can guide the response, but engineers must retain ownership, especially where remediation could affect downstream data or client reporting.

Incident management is about reaching understanding faster

Incident management is where SRE turns from monitoring into coordinated action.

An alert may show that something needs attention, but incident management determines ownership, impact, escalation and communication. For our clients, that distinction matters. A failed pipeline, delayed report or incomplete dataset can affect delivery even when the wider platform appears healthy.

AI can help by reducing the time it takes to understand what is happening. During an incident, engineers need context fast: logs, recent job runs, upstream dependencies, previous incidents and external platform signals. Gathering that manually can slow the early stages of response.

As Ardent’s technical leads made clear, AI’s immediate value is not always full resolution. In many cases, it is helping engineers reach a reliable diagnosis sooner.

That is especially important in the data environments Ardent supports, where incidents are not always visible at the point of failure. A downstream report issue may begin with upstream data arriving late, a job may still be running but drifting beyond normal behaviour, or several smaller alerts may only reveal their importance when viewed together.

By connecting signals across logs, runtimes, retries, dependencies and previous incidents, AI can help incident teams move from isolated symptoms to a clearer view of cause and impact. For Ardent’s clients, that means risk can be understood earlier, especially where reporting timelines, data availability or delivery commitments are involved.

For known and recurring incident types, that context can also support more controlled recovery. One example raised in our discussion was Ardent’s report rerun and reship process; when a report fails after multiple retries, manual intervention may still be needed to confirm that the required data is available and that a rerun is safe. AI can help identify when those conditions are met and recommend the next action.

Laxman summed it up nicely: “AI should inform the engineer — the engineer must then own the outcome.”

The same principle applies to incident documentation. PagerDuty notes, Slack discussions and resolution timelines contain valuable detail, but can be difficult to capture cleanly while the team is focused on restoring service. AI can help turn those inputs into structured incident reports, improving post-incident review and feeding better learning back into runbooks, monitoring and engineering priorities.

This is where AI-assisted incident management becomes valuable. It is not just about investigating faster. It is about understanding risk earlier, taking controlled action more confidently, and making sure every incident improves the next response.

Alert triage separates signal from noise

Alert triage is where SRE protects engineering attention.

A good alert helps engineers act. Too many low-value alerts do the opposite. They create noise, slow down response and weaken trust in the monitoring system. In data operations, that can directly affect clients: one upstream issue can trigger several downstream alerts, while a slow runtime drift may not breach a fixed threshold until a reporting window is already at risk.

This is where AI can add practical value for Ardent. One of the clearest opportunities identified in ourfact findingdiscussion was intelligent alert grouping. Instead of creating separate incidents for every downstream symptom, AI can identify alerts that appear to share a common cause and group them together. That helps engineers focus on the issue that matters, rather than chasing each symptom individually.

AI can also improve how alerts are judged. Traditional alerting often depends on fixed thresholds, but live data environments rarely behave in a fixed way. A runtime that is normal for one pipeline may be unusual for another. A delay that is acceptable at one point in the day may be critical during a client reporting window.

By evaluating alerts in context, AI can consider time of day, historical job behaviour, upstream data volumes, previous incident patterns and external platform status. That makes it better suited to spotting early signs of risk, such as gradual runtime drift or repeated retries, before they become visible failures for clients.

This is also important for alert fatigue. AI can help prioritise alerts, route them to the right engineer and reduce false positives without weakening genuine anomaly detection. If AWS, GitHub, Databricks or another platform is experiencing an active issue, AI can also connect that external context to internal alerts, helping engineers understand whether multiple alerts may share the same cause.

For Ardent’s clients, the value is earlier and clearer intervention. The sooner the right signal is identified, the more time there is to act before reporting timelines, data availability or delivery commitments are affected.

The risk is that AI gets the classification wrong. A suppressed or downplayed alert could lead to a silent pipeline failure, a missed SLA or a cascading incident across dependent workflows. It could also create gaps in the incident record, making root-cause analysis harder later.

That is why a hybrid model is the right path. AI should support grouping, prioritisation and contextualisation, but rule-based alerting should remain as a safety net, particularly in early deployment phases. Human review should remain in place for AI-driven suppression across critical workflows.

Alert triage is not just about reducing noise. It is about protecting the signals that matter most to clients, and making sure engineers can act on them with confidence.

Why this matters across complex data environments

This becomes even more important when data operations span multiple platforms and dependencies.

A client-facing issue may appear in one place but begin somewhere else. A delay in a reporting workflow might be caused by upstream data availability, warehouse performance, orchestration logic, cloud infrastructure or the way a platform such as Databricks, Snowflake or Redshift is processing a workload.

That is why SRE cannot rely on platform-level visibility alone. Teams need enough operational structure to connect signals across the stack and understand what they mean for the delivery outcome.

AI can strengthen that response by finding patterns across systems faster than a person could manually, but only when there is enough structure for it to work from: reliable documentation, useful incident history, meaningful alerts and clear decision routes.

For Ardent, this is an important part of helping clients operate mature data environments. The aim is not to monitor each platform in isolation, but to understand how those environments behave together, where reliability risk is forming and how to respond before delivery is affected.

What this means for SRE

AI will not make SRE stronger simply by being added to the workflow. It becomes valuable when it improves the quality of operational decisions: what to trust, what to escalate, what to automate and what to leave in human hands.

That is the real opportunity for Ardent and for the clients we support. AI can help teams act earlier and with better context, but only when it is built into a reliability process that already has clear ownership, strong documentation and disciplined escalation.

The next question for businesses is not simply whether AI belongs in SRE. It is whether their SRE foundations are strong enough to use AI safely, effectively and with confidence.

A big thank you to Laxman Amrale, Lead Data Architect, and Shoaib Mulani, SRE and AI Lead, for sharing their knowledge and expertise on how these practices are evolving in live data environments.