Recover the scheduled report without repeating the morning

The 09:00 reliability report times out. There is a file in the folder, and there may be a message in the channel. Pressing Retry could finish the job, or create a second report and announce it twice.

This hypothetical job reads incident records, uses Python to calculate the preceding seven complete days, saves a report and posts its link. What the team is owed is one correct report for one period, delivered once. Recovery begins by finding which parts already happened.

Name the period before the work begins

Fix the reporting interval and time zone before retrieving data. Otherwise a retry across midnight may accidentally make tomorrow’s report. An identifier such as reliability:2026-10-20 can name the report ending October 20 in the agreed zone. Store the actual start and end too, so nobody has to infer the date convention.

A retry at 09:20 still owes the 09:00 report. Tomorrow’s run owes another. Keep one report identity and separate attempt identities, then asking whether this report already exists does not confuse repeated execution with a new day.

Part of the job	What the report needs to retain	Why it changes recovery
Input	Report identity, fixed period, timezone and source snapshot or retrieval time.	A retry must use the intended period; changed input must remain visible.
Calculation and writing	Required Python calculation, permitted incident source and any model requirement that affects acceptance.	Missing dependencies can stop preparation before an external write.
Delivery	Approved folder and channel, with file and message identifiers when available.	The operator can inspect the places the job was authorized to change.
Recovery	Attempt identifier, deadline, last established stage and unresolved outcome.	The next attempt can continue the unfinished step.

The execution contract is the agreement about what the job needs, may change and must establish as finished. Its fields should answer real recovery questions. Credential role and destination can help; secret values do not belong. A source version can help when available. Retrieval time says when collection occurred, but cannot reconstruct a source that changed during collection.

Check the means to make this report

Before that 09:00 report can reach its folder, something has to calculate the week’s figures. In our example, Python needs the incident records; delivery then needs access to the folder and channel. A model selected in a setup screen cannot supply a missing source or tool. Its identity matters too when it affects what counts as an acceptable report or what the run costs. The scheduled runtime has to obtain the things this particular job needs.

A user report about ChatGPT scheduling raised differences in model and environment behavior across surfaces. That is one user’s experience, not a product-wide guarantee. It does suggest a useful question for our constructed report: will the place running the scheduled job have the same means to do the work as the place where it was set up?

OpenAI’s training material and scheduled-task walkthrough recommend trying work in ordinary chat and reviewing completed runs. For this report, a rehearsal can follow the work all the way from opening the incident source to calculating the figures and saving a draft in the intended folder. That gives us something more useful than a successful setup screen to inspect. It still does not tell us what will happen at 09:00 tomorrow: inputs, permissions and availability can change, so the scheduled run needs its own check.

If the team runs the job through an SDK, it can look to OpenAI’s model guidance for explicit production model selection, and to the API reference for pinned versions and evaluations. Those are API practices. They do not show that a ChatGPT task surface exposes the same controls. The two interfaces should not be treated as interchangeable just because both can describe the same report.

When the run finishes, the useful comparison is between what was intended and what actually made the report: the runtime, the calculation and the tool access it required. The resolved model identity belongs in that record where it is exposed and relevant. If a required dependency cannot be guaranteed or revealed, our report needs a smaller promise, such as a draft for someone to review, or an interface that can provide it. A plausible-looking file made by an unexplained substitute is not the same completed job.

Inspect the file and message as separate writes

Saving the report and announcing it feel like one delivery to the reader, but they are two writes. Keep the file and message identifiers each destination returns. A verified file should not be recreated merely because the announcement failed.

Timeout does not mean nothing happened. Read the destinations. Where an API supports an idempotency key, retry the same operation with the same key under its documented guarantee. AWS’s explanation shows how a caller-provided identity distinguishes a repeat from new intent.

A predictable filename only helps find the report. Two workers can both search, see nothing and write. Preventing that needs destination-enforced uniqueness or a suitable idempotent operation, including its scope and retention limits.

The channel needs its own reconciliation. A found matching message establishes more than an empty search result: delayed or incomplete listings may hide an already-sent message. If the outcome cannot be settled, keep “notification unknown” visible rather than send again to discover it as a duplicate.

Continue from the result you can establish

Open the report. Check its period, source context and calculation, not only its name. If correct, preserve it while establishing delivery:

Observed state	Next step for this report
Verified report and matching message are present.	Record both identifiers and accept delivery.
Verified report is present; the message is established absent through a supported mechanism.	Continue only the notification step under its retry policy.
Verified report is present; message outcome cannot be settled.	Retain the report and hold notification as unknown for review.
The file is absent, incomplete or for the wrong period.	Resolve that preparation or write outcome before announcing a report.

The incident-response evaluation guide separates the agent’s claim from independent outcome evidence. For a worker you operate, the supervised-worker guide covers timeout, cancellation and ownership at the host.

Keep the machinery proportionate. A reminder needs less than this report because it has neither a calculation dependency nor two destinations that can disagree. Check the actual scheduling interface and a completed run before relying on it; capabilities change.

The timeout can now lead to a small next step instead of a complete restart. Preserve a verified report, accept delivery when the matching message exists, or leave one named notification question for review. That is how tomorrow’s useful schedule avoids repeating today’s unfinished morning.