> ## Documentation Index > Fetch the complete documentation index at: https://docs.sitespy.app/llms.txt > Use this file to discover all available pages before exploring further. # Watch Health & Failure Alerts > How Site Spy detects a broken watch, tells you about it, and retries A monitor that quietly stops monitoring is worse than no monitor at all. If a site adds bot protection, a page moves, or a filter stops matching, Site Spy does not leave the watch to fail in silence: it classifies the failure, shows a health badge on the watch, and emails the owner. Health alerts are **operational messages about your own watches, not a paid feature**. They are sent on every plan, including Free, and are never gated behind a plan tier. ## Health states Every watch returned by the dashboard, the extension, and the API carries a `health` object with a state, a plain-language reason, and a suggested action. | State | What it means | What to do | | ------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------- | | `healthy` | The last check completed normally | Nothing | | `never_checked` | The watch has not run yet | Wait for the first check | | `recovering` | A temporary problem — network, browser, or an error on our side | Nothing; retries continue automatically | | `blocked` | The site refused automated access or served a challenge page | Look for a feed, mobile, print, or API version of the page | | `rate_limited` | The site asked us to slow down | Nothing, or widen the check interval if it repeats | | `authentication_required` | The page is behind a login | Add credentials or [Browser Steps](/docs/dashboard/browser-steps) | | `target_unavailable` | The page returned an error or is gone | Open the URL yourself and update the watch | | `empty_content` | The page loaded with no readable text, usually JavaScript-rendered | Switch the watch to browser mode | | `filter_broken` | Your CSS/XPath filter no longer matches anything | Re-pick the element in the watch editor | | `notification_failure` | The check worked, but the alert could not be delivered | Fix the notification channel — see below | | `auto_paused` | We stopped checking after a long, unrecoverable failure | Resume the watch after fixing the cause | The dashboard watch list and the extension popup both show this state. The API exposes it on `GET /api/v1/watch/{uuid}` and in the watch list response. ## When you get an email Site Spy counts consecutive failed checks per watch and emails the owner once per failure episode. | Plan | Alert sent after | | ------------------------------------------------------- | --------------------------- | | Free | 5 consecutive failed checks | | Starter, Pro, Business | 3 consecutive failed checks | | Starter, Pro, Business — site blocking or broken filter | 2 consecutive failed checks | A single episode produces one email, not one per check. If the watch recovers and later breaks again, or breaks in a different way, you are alerted again. Repeat alerts for the same unresolved problem are suppressed for 7 days. Each email says what went wrong, what to do about it, and reminds you that change notifications from that watch are paused until it recovers. Broken CSS/XPath filters have a second, separate alert that fires after the filter misses 3 times in a row. ## Retries and auto-pause A failing watch is not dropped. It is retried on a widening schedule that depends on what went wrong — minutes for a rate limit, hours for a bot wall, a day for a missing page — and the next retry time is visible on the watch. Some failures never lead to a pause, because pausing would not help: * **Rate limits** always resolve on their own. * **Network errors, browser failures, and internal errors** mean the check did not complete, not that the page is unmonitorable — often the fault is ours, not the site's. Failures that do not resolve are eventually paused so we stop hammering a page that cannot be read: | Failure | Paused after | | ------------------------------------------- | -------------------------------- | | Login required, page not found, invalid URL | 3 failures over at least 1 day | | Site blocking, empty content, broken filter | 7 failures over at least 7 days | | Anything else | 10 failures over at least 7 days | An auto-pause always sends its own email — it is the end of the episode, and you should never discover it by noticing the silence. Resuming or editing the watch from the dashboard clears the error and queues an immediate check. ## Where alerts are delivered Health alerts go to the watch owner's own channels, in this order: verified email, Telegram, then webhooks. They are never sent to a shared or operator-wide address. Brand-new accounts receive alerts at their unverified address for the first 7 days, with a prompt to verify. Alerts cannot be delivered if the watch has no owner channel — for example an anonymous extension user with no account, an address that was never verified after the grace period, or muted email with no Telegram or webhook connected. In those cases the health badge on the watch is the only signal, so if you rely on a watch, [connect an account](/docs/getting-started/connecting) and [verify your email](/docs/dashboard/email-notifications). ## Related * [Email Notifications](/docs/dashboard/email-notifications) * [Managing Watches](/docs/dashboard/watches) * [CSS & XPath Filters](/docs/dashboard/css-xpath-filters)