Table of Contents
Firecrawl /monitor with n8n or Make: build an AI agent that reacts when the web changes
If your agent watches a web page by re-scraping the whole thing every 15 minutes, you are paying to read the same 50KB of HTML 96 times a day to catch the one change that matters. The footer, the nav, the cookie banner, the unchanged body copy: all of it goes through your model again on every poll. That is the cron-polling tax, and it is the exact thing Firecrawl's /monitor endpoint is built to kill. It runs the schedule for you, diffs each check against the last snapshot, and only pings your agent when something meaningful actually changes, sending up to 90% fewer LLM tokens because your agent ingests the diff instead of the full page (Firecrawl, May 27 2026). The decision this guide answers: is that worth a plan upgrade, and which orchestrator (n8n or Make) should catch the webhook on the other end.
We wired both up against the same monitor and the build is short either way. The interesting part is the cost model and which platform you'll still be maintaining in six months.
The problem with cron-polling, priced out
Polling is the default because it's the obvious thing. You set a schedule, fetch the page, hand it to a model, ask "did anything change," repeat. It works until you look at the bill.
Two costs stack up. There's the scrape cost (every poll is a full page fetch) and the token cost (every poll feeds the full page to your LLM). The token side is the one that hurts, because frontier-model input pricing turns "read this whole page again" into a line item you pay 96 times a day per URL.
Example. Watch one 50KB page (roughly 12,000 tokens of cleaned content) every 15 minutes. That's 96 polls a day, about 1.15M input tokens daily per URL, just to notice a change that might happen once a week. Run that across 20 competitor pages and you're feeding ~23M tokens a day to a model to mostly confirm nothing happened. The diff that actually matters is a few hundred tokens.
That's the asymmetry /monitor exploits. Polling cost scales with how often you check. Diff cost scales with how often the page actually changes. Most pages you care about change far less than you poll them.
What /monitor actually does
/monitor is the whole monitoring stack collapsed into one endpoint: scheduled checks, snapshot storage, diffing, noise filtering, and webhook delivery with retries (Firecrawl). You describe what to watch in plain English and Firecrawl configures the URLs, the logic, and the schedule. You can watch a single page or a whole site, and track the full page or drill down to specific fields.
The pipeline, per Firecrawl's launch post:
- Create a monitor for one or more pages, or an entire site.
- Firecrawl scrapes on your schedule (every 5 minutes, hourly, daily, or a custom cron) and stores a snapshot.
- On each check, the new version is diffed against the last stored snapshot.
- If something changed, Firecrawl sends a signed webhook (or email) with the structured diff and a permalink.
When nothing changed, nothing is sent. No polling loop on your side, no wasted model calls. The diff is structured (what was added, what was removed, what changed) and ads, timestamps, and session tokens get filtered out so your agent doesn't wake up for noise. Delivery is a signed webhook with custom headers and per-event subscriptions, so your agent only fires for events it subscribed to.
Here's the shape of creating a monitor through the API. The endpoint takes a plain-English description and a schedule, and a webhook target.
curl -X POST https://api.firecrawl.dev/v2/monitor \
-H "Authorization: Bearer <YOUR_FIRECRAWL_API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"prompt": "Watch the pricing table on this page and notify me when any price changes",
"urls": ["https://example.com/pricing"],
"schedule": "0 * * * *",
"webhook": {
"url": "https://your-n8n-host/webhook/firecrawl-monitor",
"headers": { "X-Webhook-Secret": "<YOUR_SHARED_SECRET>" }
}
}'The exact field names follow Firecrawl's monitoring docs; check docs.firecrawl.dev/features/monitoring for the current schema before you ship, because the endpoint shipped in late May and the SDKs are catching up. The dashboard route at /app/monitoring does the same thing without writing the call.
When a change fires, the webhook body carries the structured diff. Your orchestrator reads it, optionally hands the changed text to a model for a one-line summary, and routes the result. That's the whole pattern.
Firecrawl pricing, June 2026
Monitoring is live for every Firecrawl plan, including Free. What changes per tier is the credit allowance, and a monitor check costs credits the same way a scrape does.
The credit line that matters: a monitor check costs 1 credit per page per check (Firecrawl pricing, pulled June 6 2026). A plain scrape is also 1 credit per page. So the credit you spend is set by how many pages you watch times how often you check, not by page size. That's the structural win over a cron-poller, where size and frequency both bite.
| Plan (source) | Monthly price | Credits / pages | Concurrency | Fits |
|---|---|---|---|---|
| Free | $0 | 1,000 | 2 | Trying one or two monitors at a slow cadence |
| Hobby | $16/mo | 5,000 | 5 | A handful of pages, hourly or slower |
| Standard (recommended) | $83/mo | 100,000 | 50 | Dozens of pages at minutes-level cadence, or a small site crawl |
| Growth | $333/mo | 500,000 | 100 | High-volume, multi-site, 5-minute cadence at scale |
| Scale | $599/mo | 1,000,000 | 150 | Production data pipelines |
| Enterprise | Custom | Custom | Custom | SLA, zero-data-retention, SSO |
Prices are the yearly-billed monthly rate as shown on Firecrawl's pricing page on June 6 2026. Sign up on the Firecrawl Hobby plan if you're watching a small set of pages; jump to Standard once your check budget gets real.
A quick way to size your tier: multiply pages by checks-per-day by 30. Watch 10 pages hourly and that's 10 x 24 x 30 = 7,200 credits a month, which clears Hobby's 5,000 and lands you on Standard. Drop to a 6-hour cadence and the same 10 pages cost 1,200 credits, comfortably inside Hobby. The cadence dial is your cost dial.
Firecrawl also shipped a one-click install on the Vercel Marketplace on May 26 2026, with the API key auto-injected into your project environment (Firecrawl). If you deploy your webhook handler on Vercel, that removes a step.
Workflow A: Firecrawl /monitor plus n8n
This is the build for anyone who self-hosts or wants the logic to live in a workflow they own. n8n's Community edition is free with no license key; a self-hosted install runs every node we use here (n8n docs).
Setup. Get n8n running. Docker is the cleanest path.
docker run -d --restart unless-stopped \
--name n8n \
-p 5678:5678 \
-e N8N_HOST=your-n8n-host \
-e WEBHOOK_URL=https://your-n8n-host/ \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8nWEBHOOK_URL matters. n8n builds the public webhook address from it, and that's the URL you hand to Firecrawl. Get it wrong and the monitor fires into a 404.
Step 1: the trigger. Add a Webhook node (n8n's HTTP-trigger node). Set the method to POST and copy the production URL it generates. That URL goes into the webhook.url field of your monitor.
Step 2: verify the signature. Firecrawl sends signed webhooks with custom headers. Add a small check so a random POST can't trigger your agent. A Code node does it:
// Code node: reject anything without the shared secret
const got = $input.first().json.headers['x-webhook-secret'];
if (got !== $env.FIRECRAWL_WEBHOOK_SECRET) {
throw new Error('Bad or missing webhook secret');
}
return $input.all();Step 3: pull the diff. The webhook body carries the structured diff. Reference the changed content with an expression like {{ $json.body.diff.changed }} (confirm the exact path against your first real payload; log one and read it). Pass that, not the full page, to the next node. That's the whole token saving: the model sees the diff.
Step 4: summarize with an LLM. Drop in n8n's AI Agent node (the LangChain-based root node) or a basic LLM node, wired to whichever model provider you use (n8n AI nodes). Prompt it with the diff: "Summarize this pricing change in one line; flag it as a price increase, decrease, or new SKU."
Step 5: route the alert. Add a Slack node (or email, or a database write). Post the one-line summary plus the permalink Firecrawl included, so a human can click straight to the change.
Five nodes: Webhook, Code, the diff extract, the LLM, Slack. The catch most people hit is step 1, the public URL. If you're behind NAT on a laptop, Firecrawl can't reach localhost:5678. Either deploy n8n somewhere with a public hostname or tunnel it. n8n Cloud sidesteps this entirely; the Starter plan is 20 EUR/mo billed annually for 2,500 workflow executions, Pro is 50 EUR/mo for 10,000 (n8n pricing). Note n8n bills by execution regardless of complexity, so a five-node monitor handler is one execution per fired change, and you only get charged when the page actually changed. The pairing is naturally cheap.
Workflow B: Firecrawl /monitor plus Make
If your team already lives in Make, do it there. The build is shorter because Make's HTTP webhook trigger and built-in modules carry more of the plumbing.
Step 1. Create a scenario. Add a Custom webhook as the trigger. Make generates a URL the moment you add it. Copy it.
Step 2. Paste that URL into the monitor's webhook.url. Run one real check (edit the watched page, or use the dashboard's test) so Make captures the payload structure. Make's "Redetermine data structure" reads a live payload and maps the fields for you, which is the part that's fiddlier in n8n.
Step 3. Add a filter after the webhook so only meaningful diffs continue. You can filter on the diff type Firecrawl returns and drop anything you don't care about.
Step 4. Add an AI module (Make connects 350+ AI apps, and ships a built-in AI agent layer in beta) to summarize the changed content (Make pricing, pulled June 6 2026). Feed it the diff field, not the whole page.
Step 5. Add a Slack or email module for the alert.
Make bills in credits now (it moved off the older "operations" naming). Free is 1,000 credits/mo at $0, Core is $12/mo for 10,000 credits, Pro is $21/mo for 10,000, Teams is $38/mo (Make pricing, June 6 2026). Each module run is one credit, so a four-module monitor handler burns about four credits per fired change. If a page changes 50 times a month, that's ~200 credits: well inside Core. Start a Make account on Free to prototype, move to Core when you wire in more monitors.
The honest tradeoff: Make is faster to stand up and the data-mapping is friendlier, but you pay per run forever and the logic lives on someone else's servers. n8n self-hosted is more setup and more YAML-shaped thinking, but it's free to run and the workflow is yours. That's the same split that shows up on every Make-vs-n8n call, and /monitor doesn't change it.
Which tier and platform fits which use case
Map your actual job to a row. The cadence column is the real cost driver; everything else follows from it.
| Use case | Cadence you need | Firecrawl tier | Orchestrator |
|---|---|---|---|
| Competitor pricing watch (5-20 pages) | Hourly | Standard | n8n if self-hosting, Make if not |
| Docs / changelog alert for a few sources | Daily | Hobby | Make Core (fast to wire) |
| Job-board scrape (one busy site) | Hourly | Standard | n8n (custom filtering) |
| Content / news feed for a research agent | Every 5 min | Standard or Growth | n8n self-hosted (volume) |
| Status-page monitor (1-3 pages) | Every 5 min | Hobby | Make (simple route to Slack) |
| Regulatory / filing watch (low volume) | Daily | Hobby or Free | Make Core |
The pattern in the table: high cadence or many pages pushes you to Standard and tilts toward self-hosted n8n on cost. Low-volume, slow-cadence jobs sit happily on Firecrawl Hobby (or even Free) paired with Make for the quickest build.
When /monitor is worth it, and when to stay on a cron
Use /monitor when the page changes far less often than you'd need to poll it, and when a missed change costs you something: a competitor price drop you reacted to a day late, a doc change that broke your integration, a filing you needed within the hour. That's most real monitoring. You stop paying to re-read unchanged pages, and you get a clean structured diff instead of writing your own snapshot-and-diff plumbing.
Stay on a simple cron when you're watching a page that changes on nearly every check anyway (a live feed, a constantly updating dashboard), because then the diff isn't saving you tokens, or when you already have snapshot storage and diffing built and it's working. /monitor replaces that machinery; it doesn't add magic on top of a page that's always different.
For the build itself: if nobody on your team self-hosts and you want it running this afternoon, do it in Make on Core. If you want to own the workflow, keep costs flat as monitors multiply, and you're comfortable running a container, do it in n8n self-hosted. The middle ground (you want n8n's model but not the ops) is n8n Cloud Starter.
Our pick for the common case, a small team watching 5 to 20 pages and reacting to changes: Firecrawl Standard for the check budget, paired with self-hosted n8n if you already run infra, or Make Core if you don't. The Firecrawl plan is the line item that scales with your watch list; the orchestrator is a rounding error either way because you only pay it when a page actually changes.
Get started
Spin up a free monitor first. Create a Firecrawl account on the Free plan, point one monitor at a page you care about, and watch the webhook fire only when it changes. When your check budget outgrows the Free credits, the Hobby and Standard tiers in the pricing table above are the upgrade path. For the trigger layer, start a Make account on Free to prototype the webhook-to-Slack flow in ten minutes, or run n8n self-hosted if you'd rather own it. Wire the diff (not the page) into your model, and your agent reacts to the web in near real time without re-reading the parts that never moved.
Sources: Firecrawl /monitor launch, May 27 2026; Firecrawl pricing and Make pricing, both pulled June 6 2026; n8n pricing; n8n self-hosting docs.