
Notify your AI agent when the web changes
/monitor notifies your agent via webhook the moment pages or sites change. Use up to 90% fewer LLM tokens by only ingesting what changes on a page.
/monitor by Firecrawl provides real-time notifications to AI agents via webhook when web pages change, enabling efficient data ingestion. It reduces the usage of LLM tokens by up to 90% by only processing updated content.
Overall, commenters are excited about the product's potential and efficiency, with several inquiries about specific features and use cases.
Hey Product Hunt 👋 We're Eric, Caleb, and Nick from Firecrawl. Today we're launching /monitor, the easiest way to keep your AI agent in sync with the web. We built /monitor because we kept hearing the same thing. A lot of our customers were already using Firecrawl to watch specific pages, re-scraping the same pricing pages, docs, changelogs, and filings on a loop just to catch when something changed. It makes a ton of sense, but doing it by hand means you either over-poll and burn tokens on pages that didn't change, or under-poll and miss the update that mattered. So we turned it into a product. Point it at a URL, describe what to track in plain English, and Firecrawl checks the page on your cadence, compares it to the last version, and pings your agent over webhook the moment something meaningful changes. Your agent only ingests what actually changed, so you can cut token usage by up to 90%. There's nothing to wire up yourself. The schema, scheduling, diffing, and delivery are all handled for you, and you see the estimated monthly cost before you flip a monitor on. Changes arrive by signed webhook or email, with a permalink for every diff you can hand straight to another agent. It runs on Firecrawl's /scrape under the hood, so JS-heavy pages get tracked reliably too. If you've got an agent re-scraping the same docs, changelogs, or competitor pages on a loop, this one's for you. You can try it out here: <a href="https://docs.firecrawl.dev/features/monitoring" target="_blank" rel="nofollow noopener noreferrer">https://docs.firecrawl.dev/featu...</a> Would love to hear what you think.
<p>Been waiting for something like this. Setting up custom polling logic to watch external data sources is one of those tasks that eats 2-3 hours and nobody talks about<br><br>Been doing the "scrape on a cron + diff manually" thing for competitor tracking for months. The webhook approach is cleaner. One question/ does it handle pages that hydrate content via JS after first render?</p>
<p>Congrats Eric, Caleb, and Nick! 🔥<br></p><p>Love this build. The 90% token cut is wild. That's the number every team running AI products is quietly desperate for.<br></p><p>We pull buyer-side data into FireCoach all day long for sales prospect profiles, and the re-scrape vs. monitor tradeoff is exactly the thing we keep fighting. Going to share this with our engineering team.<br></p><p>Quick question: does the diff get summarized in natural language before hitting the webhook, or does the receiving agent still have to interpret the raw diff?<br></p><p>Either way, this is one of those "obvious in hindsight" products. Nice work!</p>
<p>the 90% token reduction is the part i wish more people talked about. running webhooks on diffs instead of full crawls is what makes long running agents actually viable in production. curious how you handle noisy DOM changes (analytics scripts, ad slots, dynamic timestamps) before triggering the webhook. is that filtered at the diff layer, or is the agent on the receiving end expected to sort signal from noise?</p>