A practical checklist for verifying automation recovery
Verify outputs, delivery and recovery evidence before calling an automation healthy.
Define the observable result
Start with the result a person needs: a published page, a readable report or a restorable archive. A successful process exit is useful evidence, but it does not establish that the result reached its destination. Record the input, execution time and expected output location before running the repair.
- Choose a small, explicit set of affected routes or records.
- Record the previous error and the exact check that reproduced it.
- Keep a copy of the configuration before changing it.
Validate each boundary
Check the producer and consumer separately. A generator can finish without writing the file expected by an upload step. A report can be valid locally while delivery fails. A page can return HTTP 200 while sending the browser into a redirect loop. Follow the same path a user or downstream task follows.
- Inspect the generated output rather than relying on a success message.
- Follow redirects and verify the final destination.
- Retest the published result after deployment has completed.
Keep the next run honest
Retain the evidence with a timestamp and a clearly stated scope. If only a sample was tested, name the sample instead of claiming complete coverage. Ensure an unchanged result stays quiet and a failed delivery can be retried. Keep a reversible previous version so a later regression can be investigated without guessing.
- Run a failure-path test as well as a success-path test.
- Confirm the next scheduled execution and its delivery destination.
- Separate repaired failures from unrelated findings that still need work.