Automation readiness checklist for repetitive ops work

Why readiness comes before automation

Repetition alone is not a reason to automate. Safe automation needs a stable process definition, a named owner after handover, bounded blast radius, and signals that show success and failure. Without those, scripts concentrate risk: they run faster than humans, at odd hours, and often with credentials that exceed day-to-day privileges.

This checklist is a go/no-go gate for operational automation—monitoring responses, provisioning helpers, scheduled jobs, and gated remediations. It is not a tool comparison. It asks whether the work is understood well enough to encode, and whether operators can still intervene when the automation is wrong.

Walk it with the people who currently perform the task and the people who will own the tooling. If ownership is unclear, stop. Automating an orphaned process produces orphaned incidents.

How to use this checklist

Start from the live process, not the ideal one. Document triggers, inputs, side effects, approval points, and what operators do on failure today. Score each checklist group honestly; a single hard no on ownership, privileges, or irreversible side effects should block unsupervised automation until mitigated.

Prefer a staged path: diagnostics and tickets first, then suggested remediations with approval, then limited auto-remediation where idempotency and blast radius are proven. Dry-run and approval modes are part of readiness, not optional polish.

Revisit the checklist when the process, systems, or team change. Automation that was safe under one ownership model can become unsafe after a reorg or platform migration.

Process clarity and ownership

1. 01

   Write the current manual path end to end

   Capture trigger, inputs, steps, outputs, and handoffs as they happen under pressure—not as a cleaned-up aspiration. Ambiguous steps are candidates for human gates, not silent automation.

2. 02

   Name a durable owner for the automated version

   Assign a role or team that will maintain scripts, schedules, credentials access, and runbooks after go-live. Author-only ownership is a failure mode.

3. 03

   Separate judgment steps from mechanical steps

   Mark decisions that require context or risk acceptance. Keep those human or behind explicit approval. Automate only steps with clear pass/fail criteria.

4. 04

   Define success criteria operators can verify

   State what “done” looks like in measurable terms (service healthy, ticket closed with evidence, config matches baseline). Vague success invites silent partial failure.

5. 05

   Confirm the process is stable enough to encode

   If the procedure changes weekly without versioning, stabilize the runbook first. Automating a moving target creates constant emergency edits.

6. 06

   Identify dependencies outside your control

   List upstream APIs, identity providers, change freezes, and vendor portals the job relies on. Decide behaviour when each dependency is down.

7. 07

   Agree what must never be automated unsupervised

   Document privileged or irreversible actions (production data deletion, firewall rule removal, mass restart) that require a person in the loop regardless of tooling.

Failure paths and blast radius

1. 01

   Enumerate timeout, partial success, and retry behaviour

   Define what happens when a step hangs, succeeds halfway, or returns unexpected output. Bound retries and backoff so a bad dependency cannot amplify into a self-inflicted outage.

2. 02

   Prefer idempotent remediations where possible

   Design actions so a second run does not double-apply harmful changes. If idempotency is impossible, require locking or a single-flight guard.

3. 03

   Limit blast radius with scope and concurrency caps

   Restrict targets by inventory tags, maintenance windows, or batch size. Prevent one job from touching the entire estate in a single unchecked run.

4. 04

   Define a fast disable or kill switch

   Document how operators stop schedules, pause workflows, or revoke the automation’s credentials during an incident—without waiting for the original author.

5. 05

   Plan rollback or compensating actions

   For changes that alter state, write how to reverse or compensate. If rollback is impossible, require stronger approvals and clearer pre-checks.

6. 06

   Handle overlapping runs deliberately

   Decide whether concurrent executions are allowed. Use locks or queues when overlap can corrupt state or duplicate tickets and remediations.

7. 07

   Route failures to people who can act

   Map failure notifications to on-call or owners with enough access to investigate. Logging alone without a human path is incomplete.

8. 08

   Test failure injection before production trust

   Exercise dependency outages, bad credentials, and partial responses in a non-production or carefully scoped dry-run. Do not discover failure modes only at 02:00.

Observability and credentials

1. 01

   Emit structured logs for start, step, and outcome

   Require correlation IDs, target identity, exit codes, and duration. Operators should reconstruct a run from logs without reading the script source under pressure.

2. 02

   Expose success and failure as monitoring signals

   Alert on job failure, missed schedules, and abnormal duration. Dashboards that only show green while jobs silently skip are not observability.

3. 03

   Avoid plaintext secrets in scripts or repos

   Use the environment’s secret store or vault patterns. Document rotation and what breaks when a credential expires.

4. 04

   Grant least privilege for the automation identity

   Create a dedicated service account or role scoped to required actions. Do not reuse personal admin credentials for scheduled work.

5. 05

   Record who or what triggered each run

   Capture schedule vs manual vs alert-driven invocation, and any approver identity for gated remediations. Audit trails matter after the fact.

6. 06

   Retain outputs long enough for incident review

   Agree retention for logs and artifacts. Short retention that disappears before post-incident review defeats the purpose of automation telemetry.

7. 07

   Document how to run the job manually safely

   Provide the exact entry point, required flags (including dry-run), and expected outputs so operators can execute during incidents without improvisation.

Change control and handover

1. 01

   Version scripts and workflow definitions

   Keep automation in reviewed source control with meaningful history. Untracked edits on a jump host are not a change process.

2. 02

   Require review for privileged or production-touching changes

   Set review rules proportional to blast radius. Cosmetic log changes and production remediations should not share the same unchecked path.

3. 03

   Use dry-run or approval modes until proven

   Ship with a mode that reports intended actions without applying them, or that requires approval. Promote to auto-apply only after evidence from real runs.

4. 04

   Align schedules with change freezes and maintenance windows

   Encode freeze calendars or explicit suppressions. Automation that ignores operational calendars creates avoidable incidents.

5. 05

   Produce a runbook that matches the shipped tooling

   Include purpose, owners, dependencies, failure behaviour, disable steps, and escalation. Generic templates that omit environment-specific detail are insufficient.

6. 06

   Train a second operator before declaring done

   Have someone other than the author disable, re-enable, and interpret a failed run. Single-person operability is not handover.

7. 07

   Schedule a post-go-live review of noise and misses

   After initial production use, review false failures, missed detections, and unexpected side effects. Adjust thresholds and gates before expanding scope.

8. 08

   Define the path to retire or replace the automation

   Document decommission steps: remove schedules, revoke credentials, archive code, and update monitoring. Abandoned jobs are latent risk.