Skip to content
Watcher Docs

Known limitations

Every one of these is a real, current constraint rather than a roadmap item.

Collection

Section titled “Collection”
  • No JavaScript is executed. Watcher fetches and extracts; it does not run a browser. A page that builds its content client-side may extract as empty. The opt-in reader tier handles many such pages; some remain unreachable.
  • Extraction is best-effort. The four-tier ladder does well on articles and notice boards, less well on heavy single-page applications and on content locked behind interaction.
  • No authenticated sources. There is no mechanism for logging into a site before collecting from it.

Timing

Section titled “Timing”
  • Polling only. No webhooks, no push from sources. An event that appears and disappears between two checks is missed.
  • No backfill. If your instance is down for a day, that day is not reconstructed when it comes back.
  • Resolution is bounded by how often the instance runs, not by the watch’s cron. See Scheduling.

Judgement

Section titled “Judgement”
  • Confidence is not calibrated. The number is the model’s own; thresholds are dials to tune with feedback, not statistics.
  • A single-model setup is weaker. Without a second-opinion key, every trigger is unverified by a second family.
  • The weak tier is deliberately noisy. It exists to surface borderline evidence rather than drop it.
  • The built-in trust list is small. Sites it does not recognise start ungraded, and ungraded sources cannot raise a confirmed alert until you add a trust rule. See Source trust.

Delivery

Section titled “Delivery”
  • email is not an alert channel. It logs to the console. Transactional account email is a separate, working feature.
  • The mobile app is Android-only. The iOS project is unmaintained.
  • An alert given up on after five delivery attempts is dropped silently — there is no distinct notification for it. Repeated notify-failed outcomes in run history are the signal.

Scale and state

Section titled “Scale and state”
  • Single process by design. The per-watch lock does not span processes, so running two schedulers against one database can duplicate work.
  • Seen-content and notified-event lists are append-only and are not pruned. Negligible for normal watches; worth monitoring for very high-volume ones.
  • Run history has no automatic retention. It grows until you prune it.
  • Watch ids are global, not per-owner: two accounts cannot both use the id demo.

Operations

Section titled “Operations”
  • Free tiers are the practical ceiling. Model requests per minute and per day, search credits, and database storage all bound how many watches you can run. See Costs and quotas.
  • GET /config/status is public. It returns booleans only — never values — but it does reveal which integrations an instance has configured.