The web page cannot be reached. The weekly report still says “no change”. This is exactly where a harmless summary turns into a misleading working state. A recurring task must therefore be able to distinguish more than news or no news.
ChatGPT supports scheduled tasks with different interfaces and access routes. The documentation recommends trying the task out in a normal chat first and looking at early runs. Our own draft monitors the date and registration status of a public event page. No automation was set up for it.
The comparison needs a known starting point
Write down which date and which registration status were last confirmed. Record the source and the as-of date alongside them. The later run must actually be able to receive this reference. A schedule alone is no proof that every earlier piece of conversation will remain available as an unambiguous basis for comparison.
A schematic reference of our own could read: “Date 14 November, registration open, confirmed from the named page on the day of checking.” The date serves here only as an artificial example value. In real use, the starting point must come from the actual source.
Three states instead of a blanket result
- Unchanged: The source is readable and the fields under observation match the reference.
- Changed: A relevant detail differs; the new value and where it was found can be identified.
- Cannot be determined: The source is missing, cannot be read or does not clearly support the required detail.
A new heading without a change of date need not be a reason to report. A single changed date, on the other hand, may be important. The task therefore describes the relevant fields and their meaning instead of treating every change in the wording of the page as a new development.
Compare the date and registration status of the named public page
with the explicitly attached baseline.
Report relevant differences with old value, new value and source.
If access fails: cannot be determined, with the reason the retrieval failed.
Unchanged descriptive texts are not a reason to report.
Do not make a booking and do not send any message to the organiser.Align the report with the decision
“There is news” leaves the actual work to you. A helpful output, by contrast, states: registration closed, previously open, relevant to the participation decision that is still pending. It also includes the place where the new status can be seen.
Observation and external action remain separate. Even if a change of deadline makes registering seem sensible, a radar task has not thereby been given a booking task. This boundary belongs in the description of the workflow.
Try out the handling before the schedule
Use three text versions of your own or a suitable test page of your own: unchanged, relevant change and missing content. Write down the expected classification beforehand. Then look at whether the output contains the correct state and usable evidence.
Only then does a schedule with a clear time zone and an appropriate rhythm make sense. A weekly check may be enough for some details and too infrequent for short-notice deadlines. A task that starts regularly is no guarantee that every delivery will arrive on time.
If the date and the registration status change at the same time, the report needs both changes. A difference found first should not crowd out the second important piece of information.
Keep the reference and the access up to date
After a confirmed change, it must be clear which state applies at the next run. Otherwise the known difference may keep appearing as if it were a new report. Decide who adopts the new reference value and where it remains available for the task.
Web tasks cannot work directly in a folder on a local computer. Other workflows may need a connected computer. Check the actual access route before you rely on a schedule. A small radar is helpful when you understand the source, the comparison and the failure state, and can follow the first real runs.
Sources and documentation status: 25 October 2026.
