ChatGPT incident updates: keep the unfinished work in the story

In this hypothetical incident, you arrive to help and read “service restored.” A welcome sentence. Then you discover the earlier jobs that failed and still need recovery. New requests are working again; the people waiting on the old ones have a different story.

ChatGPT can help write an update that leaves room for both. Give it the observations and a reader to write for, and it can organize the material into a clearer account. The useful result is not simply a smoother sentence. It is an update that lets the next responder find the unfinished work without reconstructing the incident first.

Write for the person who opens the update next

That work starts before any records enter the conversation. The approved product, account, connected tools and kinds of data determine what you may supply. ChatGPT and an application built around an application programming interface, or API, are different deployments with different controls. The workplace AI guide explains how to choose an allowed place for those records.

Once that is settled, the reader gives the writing a direction. Someone learning a runbook needs the reason behind a step. Someone comparing configurations needs to see what changed. A customer waiting for an update needs an account suited to them. Supply the source material, task and audience together, and keep the source beside the draft so the reviewer can compare meaning, not just wording.

Consider a hypothetical runbook revision. The old instructions replay every failed export. The new instructions first ask whether the original job completed. “Added a status check” describes the edit, but leaves the responder to work out its consequence: a completed job may not need replaying. Explaining that decision makes the new step easier to use.

A focused request can ask what step changed, how it changes the behavior and what the supplied material does not tell us. ChatGPT has language work to do here: turn dense or scattered records into something another person can follow. The records still supply the observations. Fluent prose supplies no extra ones.

Two observations need to survive one summary

Return to our incident with two entries in the timeline. At 14:10, new requests succeed. At 14:12, the earlier failed jobs remain unreplayed. A useful draft might say, “New requests are succeeding again; recovery of the earlier failed jobs remains open.” It is less sweeping than “service restored,” and gives the person joining a much better place to start.

The words “new requests” identify what is working. The words “earlier failed jobs” keep the unfinished work in view. Remove that second part and the reader has to reopen the timeline to discover it. Neither entry establishes that the old jobs recovered. Closing the incident is therefore a separate decision: someone needs a defined recovered state, evidence about the service and backlog, and permission to change the record. A helpful draft can explain what is known without making that decision.

The next question may be quite practical: which earlier jobs are still waiting? If ChatGPT helps draft a query to list them, keep its assumptions visible. Isolated examples with known expected results can reveal whether it selects the intended requests. A query may be valid and still return the wrong jobs, just as a command may succeed in the wrong environment. Finding and correcting that mistake takes time, even if writing the first version took very little.

The same unfinished backlog can make a useful, clearly labelled training scenario. An experienced reviewer should check the expected response before a trainee learns “everything is restored” as the answer. A low-stakes writing exercise may need only light review. That proportionate approach does not grant access to production data or permission to execute anything there.

From the supplied record to a reviewed update

Follow the draft back to its source

The supplied timeline and observations feed a draft, which a responder checks for omissions, claims and uncertainty before using the existing communication process. This is a conceptual writing workflow, not a completed incident or measured trial. Diagram labels: Approved source material: Timeline and relevant observations; ChatGPT draft: Organize and explain the supplied record; Responder review: Check omissions, claims and uncertainty; Reviewed update: Use the existing communication process.

A screenshot keeps its own time

Now put the 14:10 observation in a screenshot. ChatGPT can help explain the image or an export from that moment, but the clock still belongs in the account. “Requests succeeded at 14:10” describes the supplied observation. “Requests are still succeeding” claims something beyond it. To keep watch, a system needs incoming observations, a way to detect and evaluate changes, and a way to deliver its findings. Reading one screenshot does not provide that continuing flow.

A sentence about cause can travel too far in much the same way. “The deployment may be involved” leaves a possibility open. “The deployment caused the failure” requires incident evidence that supports the conclusion. Reading more material may add an observation; changing the deployment acts on the service itself. The production-agent guide covers the permissions, action records and limits needed for that different job.

Count the work after the first draft

To find out whether assistance helped, let a reviewer try the writing task with and without it, using authorized historical records or a constructed case. Can they find what is healthy, what remains unfinished and what the next update should communicate? Compare the completed job, including preparation and review, rather than stopping the clock when the first draft appears.

Our short “service restored” update gives that comparison something concrete to catch. The reviewer must go back to the timeline to recover the missing backlog. A draft that says those jobs recovered adds a correction as well. Record the omissions, unsupported claims, corrections, review time and usefulness of the result. Keep the important cases and configuration details with those results so a later change to the model, prompt or retrieved material can face the same questions.

OpenAI’s evaluation documentation describes defining a task and checking its outputs. You can also make this comparison with a manual set of review criteria. It does not require adopting the hosted Evals platform, which the documentation identifies as being deprecated.

The unfinished jobs are easier to find

The next responder should not have to solve a writing puzzle before finding the recovery work. In our example, the update now tells them that new requests are succeeding and the earlier failed jobs remain open. They can begin with those jobs rather than rediscover them. If ChatGPT helps produce that account with less total preparation and review, the benefit is modest, concrete and worth having: someone can get on with the work the summary was meant to explain.