You are updating four website pages through a tool. The first two updates receive confirmation. During the third, the tool reports an error or stops responding. The run ends without a clear final summary.
What changed, and what should you retry?
The third update may have failed before saving. It may also have saved successfully while its confirmation was lost. The fourth page may be untouched, but an incomplete report does not establish that. Meanwhile, the first two updates represent progress worth preserving, not work to repeat automatically.
Workflow recovery means establishing the current state of the work, preserving valid progress, and choosing a justified next action. The safest continuation point comes from what actually exists, not simply from where the original plan says the process stopped.
Understand what the interruption tells you
A tool error tells you something about the interaction with the tool. It does not always tell you whether the underlying change happened.
An update can pass through several stages: the tool prepares a request, sends it, the destination processes it, and a response returns. An interruption at different points can leave different results:
- The request never reaches the destination, so nothing changes.
- The destination rejects the request without applying the change.
- The destination saves the change, but the confirmation never reaches the tool.
- The content saves, but a related action—such as publication or notification—remains incomplete.
Without further evidence, the third page in our example has an unknown outcome, not a confirmed failure.
Before trying again, preserve the useful evidence already available: the intended changes, page identifiers, confirmation messages, error details, and any revision references. This need not become a formal incident report. For a small editorial task, keeping the tool output and opening the affected page’s revision history may be enough.
Avoid launching repeated attempts while the result remains unclear. Each attempt can add another possible change to investigate. If the original operation might still be running, check its status where the system allows it before creating an overlapping attempt.
Establish the current state
Compare the intended sequence with the current artifacts. For each step, distinguish:
- Completed: the required outcome is supported by evidence appropriate to that step.
- Failed: evidence establishes that the required outcome was not achieved.
- Uncertain: the available evidence does not establish the outcome.
- Not yet attempted: there is sufficient evidence that the step has not started.
Apply these labels to a defined outcome. “Saved” and “published correctly” are different outcomes, so a page can be complete at the saving stage while publication verification remains open.
A small recovery record
The following illustrative record captures what is known at the interruption—not the results of an investigation. The page names and changes simply make the four-page example easier to follow.
| Page | Intended change | Available evidence | Present classification |
|---|---|---|---|
| About | Replace an outdated paragraph. | The tool returned an update confirmation. | Reported completed; confirm what the acknowledgment establishes and check the current content. |
| Contact | Correct the office hours. | The tool returned an update confirmation. | Reported completed; public verification remains separate. |
| Resources | Replace an outdated link. | The tool stopped during the update without a reliable result. | Uncertain. |
| FAQ | Revise one answer. | The incomplete report provides no reliable status. | Uncertain whether attempted. |
The reviewer’s next action is to inspect the relevant saved pages or revisions and compare them with the intended edits. The record then changes as evidence becomes available. Do not label the fourth page “not attempted” merely because it is missing from the final output.
Check the source that can answer the question
Different evidence answers different questions:
- Saved content or a revision can establish whether an edit exists in the content system.
- Publication state and the public page help establish whether the intended content is available to readers.
- A behavior check establishes whether a changed link, form, or interface works as intended.
- A destination record may establish whether a related external action occurred.
- Tool output helps reconstruct the attempt, but its meaning depends on what the tool actually confirms.
A preview may show unpublished content. A cached public page may show an earlier version. If the editor and public page disagree, identify which version each view represents before concluding that the save failed.
Revision history can also help distinguish the interrupted update from an earlier edit or a later collaborator’s change. This is one practical role of document provenance: preserving enough history to interpret the artifact responsibly.
Preserve progress and check dependencies
Once the first two updates are confirmed at the required level, retain them. A stopped workflow does not make valid earlier work invalid.
Keep the prepared changes for the remaining pages, along with any source material and verification notes. Recovery should not require reconstructing the entire assignment from memory. A useful checkpoint might be as simple as:
- Which pages contain the intended changes.
- Which checks have been performed.
- Which revision or version was inspected.
- Which actions remain unresolved.
This is state management at a practical scale: preserving enough information to continue from the work’s actual condition.
Check dependencies before continuing
Independent page corrections can often be recovered separately. Correcting office hours on the Contact page does not necessarily depend on replacing a Resources link.
Other changes depend on a shared condition. A page might reference a newly uploaded document, use a revised template, or rely on a configuration change. If that prerequisite is uncertain, continuing with the dependent page may produce an incomplete or broken result.
Ask whether the next step still has valid inputs. If recovery changes an earlier output, later work that used the old output may need review—even if that later work previously completed without an error.
Decide whether repeating the action is safe
Before retrying, ask: If this action already took effect, what would another attempt do?
Replacing a field with the same intended value may leave the same content. Appending a paragraph may create a duplicate. Creating a record may create a second record. Sending a message or making a payment can produce consequences that are not resolved by checking the original content.
The investigation should be proportionate to those repeat effects. Rechecking a draft is different from risking a second payment.
Repeat-safe content does not guarantee repeat-safe effects
An operation is described as idempotent when repeating it has the same intended effect as performing it once. The scope matters. A field replacement may be repeat-safe for the field’s final value while still triggering an additional notification or another downstream action.
Do not treat an entire workflow as safe to repeat because one operation appears repeat-safe. If a system provides duplicate detection or request identifiers for retries, check its documented guarantees and limits. Adding an identifier to an arbitrary request does not, by itself, prevent duplicate effects.
Check for changes made by someone else
Even a simple replacement can become unsafe when the original input is stale. Another editor may have revised the page after the interrupted attempt. Replaying an older full-page update could overwrite that newer work.
Compare the current revision with the version used to prepare the change. Where the system supports revision checks or conditional updates, use them appropriately. Otherwise, review and reconcile the differences before saving.
The goal is not to reproduce the original request at any cost. It is to achieve the authorized change without discarding valid intervening work.
Choose a bounded recovery action
Recovery is a choice among actions, not a universal retry command. Return to the uncertain third page and let the findings determine the next step.
If the intended change is already saved
Verify that it is correct and complete the remaining checks. If publication or link behavior still needs verification, do that rather than saving the same edit again.
Once the page meets its acceptance conditions, continue to the next unresolved step. Establish the fourth page’s state before acting on it.
If the change was not applied
Determine why before repeating the operation. An invalid destination, missing permission, or malformed input needs correction. Repeating the same invalid request is unlikely to help.
If the cause was a temporary interruption, the operation is no longer in progress, and repeating it is appropriate, retry the affected step rather than restarting all four pages. Use current content as the basis for the retry.
If the outcome remains uncertain
Look for the smallest additional check that could resolve the uncertainty: a saved revision, operation status, destination record, or confirmation from the responsible person.
If repeating the action could cause harm and the evidence remains insufficient, preserve the state and pause that action. Explain what is known, what is unknown, and which decision needs authorization. These are useful automation boundaries: points where continued execution requires judgment rather than another automatic attempt.
Distinguish resuming, rolling back, and compensating
- Resuming continues from a verified point while retaining valid work.
- Correcting and retrying addresses a failed step and attempts it again.
- Rolling back restores an earlier state where restoration is available and appropriate.
- Compensating performs a separate action to address an effect that cannot simply be reversed.
Restoring an earlier page revision may reverse its content. It does not necessarily recall a notification, remove an external record, or undo an action someone took after reading the page. A correction message, for example, is a compensating action—not an erasure of the original message.
Keep the recovery within the authorized task. Discarding another person’s edits, reversing consequential actions, or expanding the assignment substantially requires appropriate authority.
Verify the recovery
A retry returning without an error is useful evidence, but it is not automatically proof that the task is complete.
Repeat the acceptance checks relevant to the affected outcome:
- Does the intended change exist in the correct saved artifact?
- If publication was required, is the intended version publicly available?
- If behavior changed, does that behavior work?
- Were newer edits preserved?
- Did the recovery create duplicate or unintended effects that need attention?
- Are the inputs for remaining steps still valid?
Keep verification bounded. Replacing one Resources link usually calls for checking the saved link and its destination, not beginning an unrelated full-site audit. A shared-template recovery may justify broader checks because its effects reach more pages.
The distinction between request acceptance and outcome verification also matters in AI-assisted work. A confident completion summary cannot substitute for evidence from the affected artifacts.
If only the saved draft has been checked, say so. If the public version or a related effect remains uncertain, keep that status visible. Do not report the entire workflow as complete simply because the last attempt succeeded.
Leave a continuation point and refine the process
A recovery note should let the next person—or the next session—continue without repeating the investigation. Record enough to make the current state understandable:
- Artifacts: the affected pages, records, and relevant revisions.
- Confirmed state: what was established and the scope of verification.
- Recovery action: what was retried, corrected, restored, or deliberately left unchanged.
- Open questions: unresolved outcomes, dependencies, or authority decisions.
- Next step: the specific action that can safely follow.
Link to detailed evidence when needed instead of copying every failed attempt into the note. This is the recovery-specific part of workflow handoffs: giving the next participant an accurate continuation point rather than only the original instructions.
Improve the weakness the interruption actually exposed
The interrupted run may reveal that the process needs clearer per-page confirmation, a visible revision reference, or a separate verification stage. It may only need a habit of checking the saved draft before retrying.
Choose refinements based on the observed problem and its consequences. Automatic retries, persistent queues, and extensive logging can be useful in some systems, but they are not necessary responses to every interrupted edit. If automatic retries already exist, examine what they repeat, how often they repeat it, and what happens when the outcome remains unknown.
Workflow refinement should make the next recovery easier to understand, not merely add more machinery.
The guiding principle is straightforward: inspect before repeating, preserve what remains valid, and continue from evidence. A workflow can stop without losing all its progress. Careful recovery makes that progress usable again while keeping uncertainty visible.