Define the run contract first

Write down what starts the job, the time basis, expected input, business effect, completion evidence, and safe containment action. Give every scheduled attempt a stable run identity and every business effect an idempotency key or a documented compensating action.

Cloudflare's Cron Trigger documentation is a useful example of the platform boundary: a configured cron trigger invokes a scheduled handler and runs in UTC. It does not define your business idempotency, input validity, delivery confirmation, or recovery policy.

Exercise normal and unpleasant paths

Use a disposable fixture or approved non-production environment. Record a normal completion, missed window, duplicate attempt, overlap, failure, retry, and reconciliation. The test must use a harmless effect. Never use a customer message, invoice, deletion, or uncontrolled integration call merely to prove a scheduler works.

Keep an operator-ready ledger

Each run should record an ID, idempotency key, owner, outcome, evidence location, and—when needed—the reconciliation decision. The local evidence/P90/scheduled-run-ledger.mjs fixture rejects duplicate IDs, blocks a second completed run with the same key, identifies missed, overlap, retry, and failed windows, and rejects reconciliation without an owner, action, and evidence link.

npm test --prefix sites/howtox.com/evidence/P90

It tests the record shape, not a cloud scheduler or a database transaction.

Decide what launch is allowed to mean

Do not enable the job until one person owns missed-run review, one person can contain duplicate effects, and a safe retry rule is written down. A useful launch decision is often narrower: enable the schedule for a test cohort, observe the ledger for one interval, and expand only after the operator can find and reconcile the evidence.

Verification checklist

  • The job's time basis, input, effect, and completion evidence are named.
  • A stable run identity and idempotency or compensation rule exist.
  • Normal, missed, duplicate, overlap, failure, retry, and reconciliation paths were exercised safely.
  • No test used customer data or a consequential uncontrolled effect.
  • An operator can find the ledger and owns the next decision.

Frequently asked questions

Does a successful test run prove the schedule will always fire?

No. It proves only the recorded fixture and path. Continue monitoring actual scheduled work and reconcile missed or ambiguous runs.

Is retrying always safe?

No. Retry is safe only when the business effect is idempotent or a documented compensation path contains a duplicate effect.