I built two personal monitors for book-production and volunteer-status updates. They read a table on a webpage, compare it with the previous saved state and send a Telegram message when something changes. Silence alone, though, cannot say whether nothing changed, the check never started or the message failed to send.
Recording execution and delivery therefore mattered alongside detecting a new status. The code and run records from May and June 2026 distinguish the start of a check, an unchanged result and an error. Those historical records do not establish that the same setup is still running.
Did the check begin?
Registering a scheduled task does not ensure that the program launches every time. The setup notes cover a 15-minute interval and the laptop’s AC-power condition. A restriction on running on battery, or a sleeping computer, can stop a check before it reaches the comparison logic.
The program logs when it begins retrieving the list. If no notification arrives, the last start time is a useful first check. A gap in execution records calls for looking at the schedule and computer state; an “unchanged” entry means that particular run reached the comparison stage. The program’s own log still cannot establish that every scheduled cycle took place.
Keeping a failed message eligible for another attempt
A state comparison needs a previous record. Saving the new state after a failed notification can erase the difference that should trigger another attempt. To protect that path, I arranged for existing items whose messages failed to have their old status restored before the state file is saved. They can then remain different on the next run.
The sender does more than wait for an HTTP request to finish. It checks the response status and Telegram’s success flag, tries up to three times by default, and raises an error if the attempts fail. Both monitors use that error to retain failed items. A successful service response is not evidence that I read the message.
The recovery has a boundary. An existing item has an old status to restore; a newly appearing item does not. The book monitor does not reliably carry that first-seen item’s failed message forward through the same mechanism. The code supports a specific repair, not a claim that every possible notification loss has been eliminated.
Detecting completion without seeing the middle step
Periodic checks do not observe every transition between visits. In the book monitor, I grouped statuses into work in progress, review pending, completed and rework. Entering either of the last two groups triggers an alert even if the monitor never saw the intermediate completion-request status.
Once a baseline exists, a new item first seen as completed or needing rework is also eligible. The program’s very first run is different: it saves the current list as the baseline without sending those alerts. The separate volunteer-status monitor does not use the same first-seen rule; it reports changes to items already in its previous list.
A further branch that watches pending volunteer certification turns itself off once no pending items remain. The log records that shutdown on 25 June 2026. Continuous operation was not the only intended end state.
What remains is code and run history for personal work. As of 7 September 2026, I have not remeasured its current operation or sustained delivery success. The part I want to retain is the way it separates several causes of silence, each requiring a different check.