A reliability checklist for scheduled AI agent jobs

Separate the schedule from proof that work began

A cron expression proves configuration, not execution. The runtime needs separate records for the expected fire time, the trigger received time, the run identifier, the worker that claimed it, and the first visible unit of work. GitHub documents that scheduled Actions can be delayed under high load and that sufficiently busy queues can drop jobs, which is why the operator needs missed-run detection outside the scheduler itself.

Give every expected occurrence a stable key derived from the workflow and scheduled interval. A monitor can then compare expected keys with received and completed keys without guessing from log text. When a key is absent after the allowed delay, the system should create an alert and a replayable incident record. When the same key arrives twice, the second delivery should observe the first claim instead of starting another side effect.

Make progress, completion, and failure explicit

The run record should move through named states such as received, claimed, active, waiting, completed, failed, and held for review. Each transition needs a timestamp and a reason. Long model or tool calls also need a heartbeat or progress event, because an operator cannot distinguish legitimate waiting from a dead worker when the only visible state is running.

Completion should name the output artifact and downstream effects rather than rely on process exit. A workflow that wrote half a report, sent one of two notifications, and then crashed did not simply fail; it reached a partial-effect state that determines whether replay is safe. Store the checkpoint, effect identifiers, and next permitted action so recovery starts from evidence rather than memory.

Test the recovery path before relying on the schedule

Inngest describes durable functions as retriable work whose successful steps are recorded and are not repeated after a later failure. The same property should appear in acceptance evidence regardless of the selected runtime. Stop a worker after one completed step, repeat the trigger, force a dependency timeout, return malformed tool output, and exhaust the retry limit. The result should show which work resumed, which work stayed complete, and which action required human approval.

Agent Runtime Reliability is implemented through Reality Contact, LLC. The buyer approves the schedule, side-effect rules, credentials, alerts, and eight scenarios, then controls the production release. The checklist and test record describe the named workflows at the tested version; they do not establish continuous availability or cover failure modes outside the accepted set.

Where the service stops

Reality Contact, LLC implements and verifies bounded runtime changes but does not certify security or availability, approve credentials, authorize consequential actions, or operate the service indefinitely. The buyer approves boundaries and scenarios, controls every production credential and release, and moves workflows only after reviewing the evidence. This is software implementation and technical verification; it does not replace the buyer's security, privacy, legal, compliance, or production-readiness review. We do not promise continuous availability, error-free execution, complete incident causation, safe behavior outside the accepted scenarios, or recovery from every possible failure.