At 06:10 on a Monday, nobody on the platform team wants to read four hundred log lines. They want to know what is broken, why, and what to do. That is exactly the shape of task a language model is good at: read a lot of noisy text quickly, connect it to what is known, and say something useful in plain language.
It is also exactly the shape of task where a fluent mistake is most dangerous. People in an incident are tired, under pressure and inclined to accept a confident explanation. An assistant that says "the cause is the database connection pool" with conviction can send the team down the wrong path for an hour, or worse, into a remediation that makes things worse.
The answer is not to keep AI out of incidents. It is to be precise about which parts of incident work can tolerate a wrong guess and which cannot, and to design each part accordingly.
Four kinds of incident work
Incident response is not one task. It is at least four, and they have very different tolerances for error.
Gathering evidence. What is alerting, since when, which metrics moved, what changed recently, what the errors say. An assistant is excellent at running the right queries and summarising the results. But the facts themselves must be exact. If the summary says errors started at 05:52 and they started at 04:52, every later step is built on sand. So evidence gathering uses fixed, tested queries, and every fact in the summary links to the record it came from.
Diagnosis. Why is this happening? Here a wrong guess is tolerable, provided it is labelled as a guess. Experienced engineers form hypotheses and test them; a good assistant should do the same. The useful output is not "the cause is X". It is "three possible causes, ranked, each with the evidence for and against and a quick test that would confirm or rule it out".
Recommendation. What should we do? Options, risks and how to roll back each one. A wrong recommendation is tolerable because a person still chooses, as long as the options are honest about risk and nobody mistakes a recommendation for an instruction.
Remediation. Changing the estate to fix the problem. Here verification is compulsory. The change goes through the same controls described in Part 5, even in an emergency, and the agent checks that the change had the intended effect rather than assuming it did. Emergency change processes exist precisely so that speed does not require skipping the evidence.
One Monday morning at Ilanga
Ilanga Retail Group is fictional, and its systems and figures are illustrative. A few weeks into the approved-execution phase of the rollout, over a weekend of intermittent load shedding in parts of KwaZulu-Natal, many of Ilanga's stores traded offline, buffering sales locally. Early on Monday morning, connectivity and power returned to a large group of stores at roughly the same time, and they all flushed their buffered sales into the cloud together.
06:10. An alert fired: the age of the oldest message in the store-sales reconciliation queue on AWS had passed its threshold. The on-call engineer asked Ops Desk what was going on.
06:12. Ops Desk ran its fixed incident queries for that alert: queue depth and age over the last six hours, invocation, error and throttle counts for the reconciliation function, the dead-letter queue count, recent deployments and configuration changes to anything in that path, and the store reconnection log. It replied with a short summary and links to each result: the function was being throttled heavily from 05:58; about 3,400 messages had moved to the dead-letter queue after repeated failures; no deployment or configuration change had happened since Thursday; 61 stores had reconnected between 05:45 and 06:05.
06:15. Ops Desk posted three hypotheses, labelled as such:
- The function had reached its configured concurrency limit because of the reconnection burst. Evidence for: throttles began within minutes of the burst; concurrency at the limit. Test: compare concurrent executions with the reserved limit.
- A downstream dependency, the Azure-hosted ERP integration endpoint, was slow, making each invocation run longer and holding concurrency. Evidence for: average duration up 40%. Test: check the endpoint's latency over the same window.
- A malformed batch from one store was failing repeatedly. Evidence against: dead-letter messages came from 58 different stores.
06:24. The engineer ran the two tests. Concurrent executions sat exactly at the reserved limit of 50, and the ERP endpoint's latency was elevated but within its normal range for a busy morning. Hypothesis 1 confirmed, hypothesis 2 a contributing factor.
06:30. At the engineer's request, Ops Desk prepared a change raising the function's reserved concurrency from 50 to 120, with a check that the account's unreserved concurrency would remain above its safety floor, an estimate of the additional cost for the expected duration of the backlog, and a rollback step. Because this was production, it went through the emergency change route.
06:34. The on-call lead approved the exact change as an emergency change, as a named person.
06:41. Ops Desk applied it, tracked the update to completion as described in Part 4, and then verified the effect: throttles had stopped and the queue age was falling. It reported both facts, with links, and said plainly what it had not checked: whether the ERP endpoint was coping with the higher throughput.
07:30. The dead-letter messages were re-driven by an engineer, not by Ops Desk, after a check that none of those sales had been partially recorded already. Re-driving a dead-letter queue is a classic way to create duplicates, and Ilanga's authority map keeps it out of the agent's hands. Ops Desk helped by producing the list of affected sale identifiers for the duplicate check.
The incident took about ninety minutes from alert to clean state. The engineers estimated it would have taken about the same total time without Ops Desk, but the first twenty minutes, which they would usually have spent gathering data across two consoles, took five. More importantly, the team spent its attention on the decisions, not on the queries.
Where hallucination is tolerable
The phrase "AI hallucination" tends to be used as if it were uniformly unacceptable. In incident work, it is more useful to ask what a wrong output costs at each stage.
- A wrong hypothesis that is labelled as a hypothesis and comes with a test costs minutes. Engineers produce wrong hypotheses all the time; it is how diagnosis works.
- A wrong recommendation costs little if a person chooses and the risks are stated, and a lot if the recommendation is phrased as an instruction to a tired person at 06:15.
- A wrong fact in the evidence is expensive, because it poisons every later step and is rarely rechecked. That is why evidence gathering uses fixed queries and links every claim.
- An unverified remediation is the most expensive of all, because it can make the incident worse while everyone believes it is fixed.
Designing for this means giving the model room where its errors are cheap and taking it away where they are not.
After the incident
Ops Desk's last contribution was the first draft of the incident record: a timeline built from the evidence store, with every agent action, approval and result already recorded. The engineers corrected two details and added the decisions they had discussed by voice. The post-incident review then produced three actions: a permanent change to reserved concurrency based on reconnection patterns, a load test that simulates a mass reconnection, and a new fixed query for Ops Desk's incident set that compares store reconnection volume with queue depth.
That last action is the real feedback loop. The agent's incident queries are a curated runbook, and every incident should improve them. CloudNala's Agent Evidence Layer series covers how to turn incidents into evaluations that guard against regressions.
Key points
Incident work is four jobs. Evidence, diagnosis, recommendation and remediation each tolerate error differently.
Evidence must be exact. Fixed queries and linked records, every time.
Hypotheses are welcome if labelled. Ranked, with evidence for and against and a test for each.
Remediation needs verification. Emergency changes still need approval, tracking and a check that the fix worked.
Keep risky manual steps manual. Re-driving failed messages can create duplicates; a person should run it after a check.
Next: Part 7, The cloud operations agent reference architecture. All parts are on the series page.
How CloudNala can help
We help operations teams bring AI into incident response without handing it the incident: fixed evidence queries for your most common alerts, hypothesis-and-test formats that keep diagnosis honest, emergency change routes that still bind approval to an exact change, and post-incident loops that improve the agent's runbook each time.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Operations AI Review or write to us at consult@cloudnala.co.za