PRODUCTS & SYSTEMS · 2026 · TWO PERSONAL MONITORS · CURRENT OPERATION UNVERIFIED
No notification could mean either “nothing changed” or “the monitor never ran.” I discovered several missed events in two personal monitors for book-production and volunteer-status changes, and each failure had a different cause.
The code, state files and run logs survive. One monitor was deliberately stopped when its purpose ended; the other’s present operation has not been checked again. Neither had external users or a service outcome.
The first monitor never started
A scheduled task existed, but its battery-power condition prevented the morning run on some days. A successful script was irrelevant if the scheduler did not launch it. I added a separate trace for the start of each scheduled cycle.
The second failure saved a state that had not been delivered
When notification delivery failed after the new state had already been written, the next run saw no change and never tried again. State persistence was moved behind confirmed delivery, with an explicit retry path for failed messages.
The third failure skipped the middle
While the monitor was down, an item appeared directly in a completed state. The old rule treated a newly seen completed item as historical and ignored it. I changed the logic so that an important terminal state could be reported even without an observed intermediate step.
Those incidents made failure telemetry more valuable than another scraping feature. A public version would require a clean package without credentials or personal activity, a fresh terms review and a runtime that does not depend on one laptop’s power state.
Project record
Period: 2026
Role: status transitions, alerts, retries, scheduled execution and repair
Internal evidence: code, state files and run logs for two monitors
External validation: none
Final outcome: three missed-event causes were repaired; one tool was intentionally stopped and the other’s current operation is unverified