firecrawl-monitor

Name: firecrawl-monitor
Author: firecrawl

27kinstalls77forks

How to install firecrawl-monitor?

firecrawl/cli/firecrawl-monitor

$npx -y skills add firecrawl/cli --skill firecrawl-monitor

Installs into the current project.

Summary

Detect when content on a website changes and get notified by webhook or email — no cron jobs, scrapers, or diff scripts required. Use this skill whenever the user wants to track changes on a page, watch competitor pricing, alert on new job postings or blog posts, monitor docs/cha

Files · 1

View on GitHub

SKILL.md

1	# firecrawl monitor
2
3	Detect when content on a website changes and get notified by webhook or email. Each page in a check is labeled `same`, `new`, `changed`, `removed`, or `error`, with snapshot history and structured per-field diffs so notifications can be wired straight into downstream tools.
4
5	Monitors come in two flavors: page monitors watch URLs you already have (a page, a list, or a whole site via crawl) for changes, and web monitors watch the whole web via search for _new_ results that match a goal — see [Web monitors](#web-monitors-monitor-the-web).
6
7	Pick a target mode by what you're watching:
8
9	\| Mode \| Flags \| Watches \|
10	\| ----------- \| ------------------------------ \| ------------------------------------------------------ \|
11	\| Single page \| `--page <url>` \| one URL, for changes \|
12	\| URL batch \| `--scrape-urls <url,url,...>` \| several URLs, for changes \|
13	\| Whole site \| `--crawl-url <root-url>` \| every page a crawl discovers, for changes \|
14	\| Web search \| `--queries <q,...>` + `--goal` \| the whole web, for _new_ results matching the goal \|
15
16	The first three watch URLs you already have. Web search is the odd one out — there's no fixed URL; it runs your queries each check and alerts on results it hasn't seen before. `--goal` is required with `--queries`. (See [Web monitors](#web-monitors-monitor-the-web).)
17
18	## When to use
19
20	- The user wants to know when something changes — and be notified about it — not just read what the page says right now
21	- Ongoing change detection on any URL: pricing, docs, changelogs, blogs, job boards, status pages, competitor sites, regulatory pages, product availability, hiring pages, top-N rankings (HN, leaderboards, etc.)
22	- Monitoring the web for _new_ results rather than changes to a known page — new launches, funding rounds, papers, news, releases, or brand mentions surfaced by search across the whole web (a web monitor: `--queries` + `--goal`)
23	- "Alert me when...", "notify me when...", "email me if...", "send a webhook when...", "ping me if X changes", "track this page", "monitor the web for...", "watch for new..."
24	- Anywhere the user would otherwise wire up cron + a scraper + a diff library + SMTP themselves
25	- Step 5 in the [workflow escalation pattern](firecrawl-cli): search → scrape → map → crawl → monitor → interact
26
27	Bias toward `monitor` whenever the request implies notifications or recurrence. A single page read once = `scrape`. A single page where the user wants to be told when it changes = `monitor --page <url> --goal "..." --email\|--webhook-url ...`.
28
29	## Why use a monitor
30
31	- Change-detection-as-a-service. Firecrawl handles fetching, diffing, judging, and notifying — all server-side. No cron, no diff library, no SMTP setup, no snapshot DB to manage.
32	- Notifications first. Webhooks (`monitor.page` as each page finishes, `monitor.check.completed` after the check is reconciled) and email summaries that only fire when something actually changed or errored. External recipients confirm via per-recipient opt-in.
33	- AI noise filter via `--goal`. Set a plain-language goal and the change judge ignores formatting, whitespace, casing, punctuation, encoding, request/session IDs, cache busters, tracking params, generic metadata, and unrelated page chrome — so notifications are about content the user actually cares about, not page churn.
34	- Structured per-field diffs. JSON-mode change tracking returns keyed diffs like `plans[0].price: "$19/mo" → "$24/mo"` instead of a wall of unified diff. Drops straight into a Slack message, CI step, or internal tool.
35	- Simple page-status model. Each pa

People who liked this also viewed

6 picks

Type

firecrawl-monitor

27kinstalls77forks

View on GitHub

How to install firecrawl-monitor?

firecrawl/cli/firecrawl-monitor

$npx -y skills add firecrawl/cli --skill firecrawl-monitor

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# firecrawl monitor
2
3	Detect when content on a website changes and get notified by webhook or email. Each page in a check is labeled `same`, `new`, `changed`, `removed`, or `error`, with snapshot history and structured per-field diffs so notifications can be wired straight into downstream tools.
4
5	Monitors come in two flavors: page monitors watch URLs you already have (a page, a list, or a whole site via crawl) for changes, and web monitors watch the whole web via search for _new_ results that match a goal — see [Web monitors](#web-monitors-monitor-the-web).
6
7	Pick a target mode by what you're watching:
8
9	\| Mode \| Flags \| Watches \|
10	\| ----------- \| ------------------------------ \| ------------------------------------------------------ \|
11	\| Single page \| `--page <url>` \| one URL, for changes \|
12	\| URL batch \| `--scrape-urls <url,url,...>` \| several URLs, for changes \|
13	\| Whole site \| `--crawl-url <root-url>` \| every page a crawl discovers, for changes \|
14	\| Web search \| `--queries <q,...>` + `--goal` \| the whole web, for _new_ results matching the goal \|
15
16	The first three watch URLs you already have. Web search is the odd one out — there's no fixed URL; it runs your queries each check and alerts on results it hasn't seen before. `--goal` is required with `--queries`. (See [Web monitors](#web-monitors-monitor-the-web).)
17
18	## When to use
19
20	- The user wants to know when something changes — and be notified about it — not just read what the page says right now
21	- Ongoing change detection on any URL: pricing, docs, changelogs, blogs, job boards, status pages, competitor sites, regulatory pages, product availability, hiring pages, top-N rankings (HN, leaderboards, etc.)
22	- Monitoring the web for _new_ results rather than changes to a known page — new launches, funding rounds, papers, news, releases, or brand mentions surfaced by search across the whole web (a web monitor: `--queries` + `--goal`)
23	- "Alert me when...", "notify me when...", "email me if...", "send a webhook when...", "ping me if X changes", "track this page", "monitor the web for...", "watch for new..."
24	- Anywhere the user would otherwise wire up cron + a scraper + a diff library + SMTP themselves
25	- Step 5 in the [workflow escalation pattern](firecrawl-cli): search → scrape → map → crawl → monitor → interact
26
27	Bias toward `monitor` whenever the request implies notifications or recurrence. A single page read once = `scrape`. A single page where the user wants to be told when it changes = `monitor --page <url> --goal "..." --email\|--webhook-url ...`.
28
29	## Why use a monitor
30
31	- Change-detection-as-a-service. Firecrawl handles fetching, diffing, judging, and notifying — all server-side. No cron, no diff library, no SMTP setup, no snapshot DB to manage.
32	- Notifications first. Webhooks (`monitor.page` as each page finishes, `monitor.check.completed` after the check is reconciled) and email summaries that only fire when something actually changed or errored. External recipients confirm via per-recipient opt-in.
33	- AI noise filter via `--goal`. Set a plain-language goal and the change judge ignores formatting, whitespace, casing, punctuation, encoding, request/session IDs, cache busters, tracking params, generic metadata, and unrelated page chrome — so notifications are about content the user actually cares about, not page churn.
34	- Structured per-field diffs. JSON-mode change tracking returns keyed diffs like `plans[0].price: "$19/mo" → "$24/mo"` instead of a wall of unified diff. Drops straight into a Slack message, CI step, or internal tool.
35	- Simple page-status model. Each pa

People who liked this also viewed

6 picks

Type