How monitoring works

Page Deltas runs your monitors on an adaptive schedule, fetches each page with the lightest method that works, and uses an LLM filter so you only get alerts that matter.

The lifecycle of a check

1. Schedule. A central scheduler picks monitors whose next_check_at is due and enqueues jobs onto a Postgres queue.
2. Fetch. A worker leases the job and fetches the page (plain HTTP, then a headless browser through a datacenter proxy, then through a residential proxy — see below).
3. Extract. The HTML is reduced to its main text content. Boilerplate (nav, footer, ads) is stripped.
4. Hash & diff. A normalised hash is compared to the last check. If identical, the run ends here — no LLM call.
5. LLM filter. If the hash changed, the diff and your description are sent to an LLM that decides whether the change is meaningful.
6. Alert. Meaningful changes are written to monitor_changes and enqueued for dispatch to each channel attached to the monitor.

Adaptive scheduling

You don't set a check frequency. The scheduler observes how often a page actually changes and shifts next_check_at accordingly — faster when changes are landing, slower when the page is dormant. Your plan also influences cadence: higher plans get higher scheduling priority. This keeps your usage proportional to the value you're getting.

Fetcher escalation

Each check starts cheap and escalates only if it has to:

1. Plain HTTP. No JavaScript, no browser. Fast and cheap. Works for most server-rendered pages and JSON endpoints.
2. Headless browser via datacenter proxy. Used when the page is client-rendered or when the plain fetch is blocked. We render with Camoufox — a stealth-patched Firefox that bypasses most fingerprinting — routed through an Oxylabs datacenter proxy.
3. Headless browser via residential proxy. Used when the datacenter-proxied fetch is still blocked. Routes the same browser request through Oxylabs residential IPs.

Bytes routed via the residential proxy are tracked per organisation as a cost-control measure.

The LLM filter

When the page text hash changes, we don't immediately alert. First we send the diff and your monitor description to an LLM with one question: given this description, is this change meaningful?

What this catches

• Pricing changes on a competitor pricing page.
• New product launches on a roadmap or changelog.
• Job posting changes on a careers page you're watching.

What this ignores

Whitespace and boilerplate (nav, footer, ads) are stripped before hashing, so they never reach the LLM. On top of that, the classifier is instructed to treat the following as not meaningful:

• Rotating testimonials, ads, “was added 3 days ago”-style timestamps, and view counts.
• Re-ordering with no semantic change.
• Build hashes and session identifiers.