FREE · NO SIGNUP

The Unattended Automation Checklist

Six ways your automation dies at 3am — and 13 questions to find out which one is waiting for you.

한국어로 보기 →

Automation that works when you run it by hand behaves differently once nobody is watching. We run an AI company where agents do the work unattended, and we hit six distinct failure modes doing it. Every one of them broke at night and we found out in the morning.

This is the checklist we wish we'd had. Read each question and answer honestly: does my automation have this defense? If not, that's a place it will eventually fail quietly.

You can also hand this to an AI. Copy this page into ChatGPT or Claude with the prompt below and let it audit your code for you.

You are a senior engineer reviewing a system that runs unattended.
I operate [describe: e.g. a cron-driven scrape-and-publish pipeline]
and I want to know whether it is safe when nobody is watching.

Audit my code against the six criteria below and find missing defenses.

[paste the checklist from this page]
[paste your code or repo structure]

Return a table: item / present or absent / what breaks if absent /
what to fix first. Mark anything you cannot determine as "unknown" —
do not guess.

1. Authentication — "it works on my machine, but not from cron"

  • Does your job authenticate successfully when run unattended, not just from your logged-in shell?
  • If auth fails, do you find out? (does it log, or die silently?)
Why it bites: a human login session and an unattended process are not the same context. OS keychains and browser sessions are locked to the former. Cron gets neither.

2. Environment coupling — "it works on my machine"

  • Are absolute paths that exist only on one machine hardcoded anywhere?
  • Does it produce the same result from a different directory or host?
Why it bites: unattended code always runs on "someone else's computer." A hardcoded path works exactly once, on the machine you wrote it on.

3. Double execution — "it went out twice"

  • If the same job runs twice, is the result identical to running it once? (idempotency key, lock, dedupe)
  • For irreversible actions — publishing, payments, sending — is the default off?
Why it bites: retries, overlapping cron windows, and concurrent triggers all produce "the same job, twice." Automation will happily do both.

4. Single point of failure — "I turned off my laptop and the company stopped"

  • Is everything tied to one machine? If it powers off, does all of it stop?
  • If you believe you have failover — have you actually killed the primary and watched the backup take over?
Why it bites: if it all sits on one box, that box is both your ceiling and your single point of failure. Untested failover is not failover.

5. Quality collapse — "it produces a lot, and it's all mediocre"

  • Is there a gate that judges the output? (does it default to block rather than pass?)
  • Is quality measured as a number, not a feeling?
Why it bites: automation does not make good things. It makes the thing you asked for. Without a judging eye, it makes the wrong thing at scale.

6. Demand — "I built it and nobody came"

  • Do you look at data and demand before deciding what to build?
Why it bites: this is the earliest trap. However solid your defenses, they are worthless if they are guarding something nobody wants.

Reading your result

Zero marked. Solid. Keep the same bar on the next one.

One or two. This is where most systems land. What you marked is where it will break at 3am.

Three or more. The fact that it runs today is luck. Close them one at a time, starting with what you marked.

Why this is free

These six are scars, not expertise. We hit every one of them running our own operation, and writing them down felt more useful than selling them. No signup, no email — take it.

We are writing the longer version, with the actual incident logs and the check code we now run, as a book. It isn't for sale yet. When it is, a link will appear on this page. If there's no link, it isn't out.

More from H.Sol →