--- name: tinyfish-site-change-monitoring description: Set up, review and maintain recurring TinyFish monitors on web pages that should be watched for change, checking each monitor's last runs, pausing, resuming or cancelling them deliberately, and reporting what changed and what is stale. Use when the user wants to watch a page or price, be alerted to a change, check whether a monitor is still working, or clean up old monitors. --- # Maintain site-change monitors A monitor is a standing instruction to look at a page again later. Its value depends on three things: it watches the right page, it runs on a schedule that matches how fast the page changes, and someone notices when it stops working. Most of the work here is reviewing existing monitors, not creating new ones. Creating, running, pausing, resuming and cancelling monitors all change state that other people may depend on. Every such step needs the user's explicit yes. ## 1. Inventory before touching anything Call `list_monitors` and page through the result rather than loading everything at once. Build a short table of the monitors that matter: name or target URL, current state, and when it last ran. For any monitor the user names, call `get_monitor` to confirm its target and configuration before deciding anything about it. Do not guess which monitor the user means from a partial name. If two candidates match, ask. ## 2. Check health from the run history For each monitor under review, call `list_runs` filtered to that monitor, then `get_run` on the most recent run to read its outcome. Health is judged from runs, not from the monitor's state field alone, because a monitor can be marked active while every recent run fails. Classify each monitor: - **Healthy:** recent runs completed, and the page is still the one the user intends. - **Silent failure:** runs complete but return no content, or the same empty result every time. This often means the page moved, now requires a login, or the goal no longer matches the layout. Treat it as broken even though nothing errors. - **Erroring:** recent runs failed. Read the error on the run before drawing a conclusion; a single transient failure is noise, repeated failures are a finding. - **Stale:** no run in the period the schedule implies. Say so; it may be paused or the schedule may be wrong. - **Expected quiet:** the page rarely changes and the monitor is correctly reporting "no change". Do not flag these as problems. ## 3. Judge whether the schedule fits the page A monitor that checks every few minutes on a page that changes weekly wastes budget; one that checks weekly on a live stock or news page misses the event it exists for. Compare the interval against how often the page is known to change. If the user does not know, say the interval should be chosen from observed change, and offer to leave it as is. Watch for duplicates: two monitors on the same URL with overlapping goals double the spend and produce duplicate alerts. Report them as candidates for consolidation, not as things to delete. ## 4. Propose changes, then wait Based on the classification, recommend one of: keep as is, fix (new goal or target), pause, resume, cancel. Show the user the monitor name, the reason and the exact action before doing it. When the user agrees to create a monitor, confirm the target URL, what counts as a change, the interval, and how the user will be told. Then call `create_monitor`. Do not create a monitor as a test without saying it will run on a schedule. To check a monitor on demand, use `run_monitor` only if the user asks for an immediate run, because it starts work now. For pause, resume or cancel: `pause_monitor`, `resume_monitor` and `cancel_monitor` each wait for the user's explicit yes on that specific monitor. Cancelling is hard to undo, so name the monitor and say it cannot be restarted from its current history, unless the docs you have confirm otherwise. If you are not sure, say you are not sure. Do not use `cancel_run` on a monitor's run without the same explicit yes; it stops an in-progress execution. ## 5. Report changes, not raw output When the user asks what changed, summarise each monitor's latest meaningful result against the previous one: what is different, when, and whether it matches the goal. Quote the specific text or value that changed. Ignore run-to-run noise such as timestamps, ad slots and rotating banners if the content shows they caused the difference. ## Common patterns and traps - **"Active" but silent.** The most common failure. A monitor reports healthy status while its runs return nothing useful. Always read a recent run's output before declaring a monitor working. - **Layout drift.** A goal written for one page design fails quietly after a redesign. The fix is a new goal, not a retry. - **Login walls and cookie banners.** A run that lands on a consent page or sign-in screen looks like a result but is not. Check that the content is the target page. - **Noise as change.** Dynamic counters, "last updated" stamps and personalised content trigger false alerts. Narrow the goal to the field the user actually cares about. - **Paging through long lists.** Load monitors and runs in pages. Dumping every run into the conversation hides the one failing monitor that matters. - **Budget surprise.** Many monitors on short intervals consume spend steadily. If the user asks about cost, read usage with the sibling usage job rather than estimating here. ## Output ``` Monitors reviewed: ( healthy, silent, erroring, stale) Monitor: — State: Last run: