Refetching everything is not monitoring.
Ask the site what moved before you spend anything reading it. One call returns every URL with the date it declares, so a run costs a credit plus whatever actually changed.
ask first · fetch second
[ 01 / How it works ]
Ask what moved. Then read only that.
Monitoring is a diff problem before it is a fetching problem. Get that order right and the cost of watching a site stops scaling with its size.
List
Map the set you watch
One call returns every URL with the last modified date its sitemap declares. That is the cheapest signal available and it costs a single credit.
const { links } = await hf.map({
url: site,
});Diff
Compare against last run
Keep the timestamps from the previous run and subtract. What is left is the only part of the site worth spending a fetch on.
const moved = links.filter(
(l) => l.lastmod > lastRun,
);Fetch
Pull only what moved
Fetch the changed pages, compare the markdown to what you stored, and raise an alert only when the text actually differs.
const pages = await hf.batch({
urls: moved.map((l) => l.url),
});[ 02 / The demo ]
A monitor, running.
Two consecutive runs against our own documentation. The first finds a release, the second finds nothing, and the difference between what they cost is the whole argument.
This is your cron job, not our endpoint. There is no monitor to switch on here: the loop above is a scheduled script calling map and batch, and the whole point is that those two are enough to build one. Most runs cost a single credit because nothing moved, which is what makes watching a site affordable at all. The runs that do find something are the interesting case, and the twenty four pages sharing one timestamp are the hard part of it. That block is a generated API reference rewritten in a single pass. Treat it as twenty four separate changes and you fetch twenty four pages to learn one thing, then send twenty four alerts about it.
[ 03 / Built for ]
Teams who need to know the moment it changes.
Anywhere a page you do not control is load bearing for something you do.
Policy and compliance
A regulator updates guidance and nobody notices for a quarter.
The run flags the changed page the morning it is published.
Pricing watch
Competitor pricing moves quietly and your deck goes stale.
Only pages that moved get read, so a daily check stays cheap.
API and docs drift
A vendor changes a response shape and your integration finds out first.
Their reference is watched, so the diff arrives before the incident.
Catalogue and stock
Listings change constantly, and full recrawls cost more than they return.
Read the pages that declare a change and leave the rest alone.
Research corpora
An index rebuilt from scratch each week burns budget on identical pages.
Re-embed only what moved and the rebuild becomes an update.
Alerting and digests
A monitor that fires on every render trains people to ignore it.
Compare the text, not the markup, so noise never reaches the inbox.
[ 04 / Keep going ]
Same API. Other problems.
Web data for AI
Ground RAG in fresh content
Crawl a site on a schedule and pipe clean Markdown into your embeddings.
ReadWeb data for AI
Give an agent the live web
Search mid-answer and get results already fetched, cleaned and citable.
ReadWeb data for AI
Turn listings into a dataset
Point a JSON schema at a directory and get typed rows back.
Read[ Start ]
Clean web data is one call away.
500 free credits, no card required. Failures are never billed.
Success rate
Median scrape
ms
