From searching for instructions to questioning the evidence

During a live data incident, the problem is rarely that engineers have no information. The problem is that the information they need is spread across too many places.

A failed Databricks job can send an engineer through logs, dependencies, catalogue information and earlier incidents. A Snowflake performance issue may require query history, warehousebehaviour, data freshness and the reporting commitments at risk. The clues usually exist; finding them, connecting them and deciding what they mean is where the time goes.

This is the gap conversational runbooks are built to close, turning static operational guidance into an evidence-led investigation. Rather than adding another tool to check, they help Snowflake and Databricks engineers assemble context, test competing causes, assess business impact and decide what is safe to do next without replacing human judgement.

Green Is Not Resolved

This is not a theoretical shift or a chat-interface exercise.At Ardent, our teams design, modernise and operate the pipelines, reporting workloads and governed platforms on which time-critical decisions depend. We begin by mapping the operational knowledge already present: platform telemetry, business deadlines, dependencies, earlier incidents, support procedures and the informal checks experienced operators make before acting.

That mapping exercise routinely surfaces the same weak points: guidance duplicated across teams, an alert that reports platform health without reflecting delivery risk, or an escalation path that assumes an owner who has since moved teams. Incident response improves once those gaps are closed, because technical evidence, business impact and approved recovery guidance can then be brought together quickly enough to support sound engineering judgement.

This is Ardent’s wider engineering ownership model in practice. We do not treat an incident as resolved simply because a platform has returned to green; the real test is whether the affected data is complete, the reporting commitment isprotectedand the cause is understood well enough to prevent repetition. A conversational runbook should carry the same discipline into the investigation, connecting technical recovery with the business outcome the platform exists to support.

The Failure Mode No Runbook Was Written to Expect

Runbooks remain essential because they make known responses repeatable. But incidents rarely arrive in the exact form anticipated by the document. A pipeline may appear healthy while runtime drifts, several alerts may share one dependency, or a platform may adapt its execution under changing demand. Snowflake’s December 2025 outage was a reminder of how far this can extend: a single backwards-incompatible schema update took ten regions offline for thirteen hours, a failure mode no standard runbookwas written to expect. The guide can describe every component correctly without explaining how the signals combine in the incident happening now.

A conversational runbook changes the order of work. Rather than searching a document and opening tools one by one, the engineer begins with the operational question: what changed, which services are affected, what supports the suspected cause and what is safe to do next? The system gathers relevant evidence, compares the live event with known patterns and shows where the match is strong or weak; the engineer tests that answer against the environment.

This does not make the underlying runbook less important. It changes its role from a fixed route through a known problem into a governed body of operational knowledge that can be applied to the evidence in front of the team. The value becomes clearer when that evidence differs across the two platforms.

The Interface Can Be Consistent; the Reasoning Cannot

In Databricks, the investigation may cross jobs, data volumes, dependencies, logs and mixedlakehouseassets. A job that has not failed but has slowed over four consecutive runs could be compared with an earlier incident, allowing the engineer to see both the similarities and the conditions that make the previous recovery action unsafe today.

Databricks separates data engineering, orchestration, compute, governance and platform status across distinct operational areas. Ardent uses the conversational layer to connect those views: bringing together a failed task, runtime changes, lineage, cluster conditions and active service events, while showing which conclusion is supported by which evidence.

In Snowflake, the evidence may centre more on query behaviour, warehouse performance, governed datasets, freshness and downstream reporting commitments. The same technical delay can be minor for one workload and critical for another, so the runbook needs both a platform-specific evidence model and a business-service model. The interface can be consistent; the reasoning context cannot.

Snowflake’s query-history functions provide strong diagnostic evidence by time, session, user or warehouse. But Ardent’s engineers still need to establish whether the behaviour is isolated, whether a delivery window is approaching and whether remedial action could disrupt another workload. Conversation adds value by connecting those layers without hiding the underlying query record.

Available Is Not the Same as Trustworthy

These pressures play out consistently in Databricks environments that mix jobs, lineage and unstructured assets: when an incident occurs, engineers need a fast route from technical symptom to downstream consequence, not another isolated source of information to reconcile against everything else.

The same discipline shows up in Ardent’s Snowflake work. On one long-running engagement, a media market research client’s platform brings together more than a billion near-real-time social media records and survey data from around 1.3 million users, with dynamic tables restructuring the feed as new categories appear and hourly checks confirming the source is behaving as expected. Environments moving that fast train engineers to treat freshness as a first-class signal: a table can be technically available and still be the wrong evidence to trust if the last check hasn’t landed.

Evidence matters more than fluency here. If a runbook recommends a rerun, workload change or escalation, the engineer must be able to inspect the logs, metrics, dependencies and approved procedure behind it, and conditions outside the runbook should escalate rather than be resolved by the system.

The useful output is not only a faster resolution but better operational knowledge: the conversation preserves what was tested, ruled out and resolved, so undocumented checks become guidance instead of disappearing into chat threads and individual memory.

That gap is not unique to Ardent’s clients: PagerDuty’s 2026 State of AI-First Operations Report found that every organisation surveyed agreed post-incident learning matters, yet only 48%turnincidents into structured learning. This mirrors Google’s SRE guidance, which treats the postmortem as a record of impact, response, causes and follow-up actions.

Conversational runbooks can support that learning loop by preserving the investigation trail and drafting proposed changes, while approval remains with the people accountable for the service.

Authority Belongs to the Action, Not the Assistant

The move from guidance to action should follow four controlled stages: retrieve, diagnose, recommend and act. Retrieval assembles approved evidence; diagnosis tests causes; recommendation exposes the safest next step and its reasoning; action executes only inside explicit, reversible boundaries. Trust should be earned at each stage rather than assumed for thesystem.

Most organisations should remain in the first three stages longer than a demonstration suggests. Retrieval carries relatively low operational risk; diagnosis requires trusted patterns and good incident history; recommendation must expose a safe option and its constraints. Ardent only advances narrow, reversible and well-observed actions to execution.

Authority therefore belongs to a specific action, not to theassistant. Restarting a low-risk task after approved checks is different from resizing shared compute, changing production logic or rerunning a customer-facing report. Reliability in one boundary does not grant authority outside it.

Better Judgement, Not a Slicker Interface

With the evidence model established early, the practical starting point is one recurring incident with a recognisable investigation path: a delayed report, incomplete source load, repeated Databricks failure or Snowflake workload that regularly exceeds its window. Ardent defines the evidence, safe recommendations, escalation conditions and language for uncertainty before introducing any automation.

The first deployment should run as decision support, not hidden automation. Its evidence and recommendation are compared with the engineer’s actual investigation. A disagreement may reveal missing data, an undocumented exception or business context the platform could not see; each gap becomes a concrete improvement before authority expands.

Success should reflect the operating outcome: time to assemble evidence, reach a credible diagnosis and choose a safe recovery path; the proportion of responses grounded in approved sources; and the incidents that improve the runbook. The aim is better judgement with less avoidable effort, not a slicker interface for its own sake.

The Distance Between Signal and Decision

Conversational runbooks are changing incident response by giving engineers one governed route through live evidence, operational knowledge and business impact. They do not remove the need for observability, ownership or platform expertise; they reveal the quality of those foundations and help disciplined teams investigate with greater speed and consistency.

Across Snowflake and Databricks, Ardent connects platform telemetry, approved recovery procedures and the delivery outcome at risk without pretending the platforms behave identically. The strongest conversational runbook is not the one that answers every question or automates the most actions; it is the one that shortens the distance between a signal and a justified decision, while leaving the operation stronger for the next incident.

If your teams are still assembling incident evidence across logs, runbooks and separate platform tools, speak to Ardent about where a conversational approach could shorten that path across Snowflake, Databricks and your wider data environment.

Sources and further reading

• Ardent: “Runbooks, Incident Management and Alert Triage: The Practical Side of AI in SRE” — the wider Ardent view of AI-assisted runbooks, incident coordination and alert triage.

• Ardent: “Migrating to Agentic AI: A Practical Roadmap for Data Teams Already Running ETL Pipelines” — a related operating model for bounded authority, evidence gates and human review.

• Ardent success story: data lake and dynamic tables delivery for a media market research client — the delivery evidence behind the Snowflake freshness example used in this article.

• Databricks documentation: Data engineering, platform operations, governance and service-status guidance.

• Snowflake documentation: QUERY_HISTORY and QUERY_HISTORY_BY_* functions for examining activity by time, session, user and warehouse.

• InfoWorld: “Snowflake software update caused 13-hour outage across 10 regions” — the December 2025 incident referenced as an example of a failure mode no standard runbook was written to expect.

• PagerDuty: “2026 State of AI-First Operations Report” — the post-incident learning statistic referenced in this article.

• Google Site Reliability Engineering: “Postmortem Culture: Learning from Failure” — guidance on using incident records and follow-up actions to improve reliability.