How to Watch a Web Page for Price Changes with Urlwatch

Urlwatch can monitor a product page by fetching it on each run, filtering the result to the price text, comparing that output with the previous run, and reporting detected changes. To keep alerts useful, target the smallest stable element containing the price, preview the filtered result, schedule Urlwatch to run regularly, and configure a reporter.

This guide uses the documented Urlwatch 2.29 workflow. Retailer markup varies, so the example selector is a placeholder: inspect the actual page and choose a selector that matches its price element. Urlwatch detects changes in page output; it does not verify the final checkout price or guarantee that a retailer will honor a displayed price.

1. Install Urlwatch and initialize its files

Follow the official installation guide for your operating system and preferred installation method. Then run Urlwatch once to initialize its configuration and state:

urlwatch

Edit the job list, usually urls.yaml, with:

urlwatch --edit

Configure report delivery in urlwatch.yaml with:

urlwatch --edit-config

Keep the state and configuration files available to the same account and machine that will run scheduled checks. Urlwatch needs prior output to compare against later runs.

2. Choose how Urlwatch loads the product page

Urlwatch supports three useful job modes:

Mode	Use it when	Tradeoff
`url`	The server returns the product price in the page content.	Simplest option; it may not include content inserted by JavaScript.
`navigate`	The price appears only after client-side JavaScript runs in a headless browser.	Can handle rendered pages, but browser setup is more involved.
`command`	You want Urlwatch to compare the output of a shell command.	Useful for a custom retrieval or extraction script; you maintain that command and its dependencies.

Start with url. If its fetched output does not contain the displayed price because the retailer renders it client-side, use navigate. The official introduction describes the job types and current setup.

3. Configure a price-monitoring job

In urls.yaml, add a job that fetches the page and applies a selector. Replace the example URL and selector with values from the product page you want to monitor:

name: Example product price
url: https://shop.example/products/example
filter:
  - xpath: "//span[contains(concat(' ', normalize-space(@class), ' '), ' price ')]"
  - html2text

This example uses XPath to select an element whose class includes price, then converts its content to text. The class expression handles a class list containing additional class names. It is only a pattern: the target retailer may use different markup, and no retailer-specific selector is assumed here.

If a site has a stable CSS class, a CSS selector is another option. For a JavaScript-rendered price, use a navigate job and keep the same idea of filtering its output to the relevant element. Consult the configuration reference for the current job and filter syntax.

Pick a selector that stays useful

Open the product page and inspect the displayed price element.
Prefer a stable identifier or a specific price class over a broad selector such as the entire product page.
Check whether the selected text includes currency, a sale price, or other price details you want alerts to track.
Run the filter preview and confirm its output before relying on notifications.

A narrow selector usually makes reports less noisy when unrelated page content changes. A broader section may survive markup changes better, but can also produce reports for stock labels, layout changes, or other text. Choose based on the page and inspect the output.

4. Preview the filtered output

Run Urlwatch’s filter test before waiting for a scheduled change:

urlwatch --test-filter

Review the result and make sure it contains the price you intend to track, with no large unrelated portions of the page. The filter may need adjustment if it returns nothing, matches multiple elements, or includes surrounding text. Preview again whenever the retailer changes its markup or you edit the filter. The configuration documentation notes that changing a filter does not retroactively re-filter stored output, so use the preview to validate the current result.

5. Configure notifications

Urlwatch reports detected changes with the job URL and a unified diff. Configure an enabled reporter in urlwatch.yaml so reports go somewhere you will see them. Available choices documented by the project include stdout, email, and integrations such as Slack, Discord, Telegram, Matrix, and Pushover. Reporter configuration depends on the destination; follow the reporter documentation for the specific integration.

Do not assume email or another remote reporter is active by default. Run Urlwatch manually after configuring it and confirm that the report reaches the intended destination.

6. Schedule recurring checks

Urlwatch only checks a page when the command runs. Schedule it on a machine that remains available and retains the Urlwatch configuration and state.

Unix-like systems: cron

For example, a cron entry can run Urlwatch every 30 minutes:

*/30 * * * * /usr/local/bin/urlwatch

Use the actual path to the Urlwatch executable in your environment. If cron cannot find the executable or configuration, use absolute paths and configure the job’s environment as needed.

Windows: Task Scheduler

Create a scheduled task that starts the Urlwatch command at the interval you choose. The official introduction mentions Windows Task Scheduler for recurring runs. Set the executable path and working environment so the task uses the same configuration and state as your manual run.

The current Urlwatch introduction recommends running no more often than once every 30 minutes. A 30-minute schedule does not provide instant alerts: a price change is reported after a subsequent run observes it.

7. Troubleshoot common problems

Symptom	Likely cause	What to do
The filter output is empty.	The selector does not match the page’s actual markup, or the price is rendered by JavaScript.	Inspect the page markup and run `urlwatch --test-filter`. If the price is client-rendered, try `navigate`.
The report includes most of the page.	The filter selects a broad container or the conversion filter leaves unrelated content.	Target a smaller stable price element and preview the filtered output again.
Unrelated page edits trigger reports.	The job is comparing broad page output instead of the relevant price text.	Narrow the filter. If a narrow selector is fragile, compare the noise against the risk of missing the price after markup changes.
Urlwatch never sends an alert.	The reporter may not be enabled or configured, or the scheduled task may not be running.	Run Urlwatch manually, verify the reporter settings and destination, then inspect the cron or Task Scheduler command and environment.
A selector used to work but stopped.	The retailer changed its HTML or class names.	Inspect the current markup, update the selector, and validate it with `--test-filter`.
Changes arrive later than expected.	Urlwatch only observes changes during a run; the schedule controls detection delay.	Check the scheduler’s run history and choose an interval consistent with the documented recommendation of at least 30 minutes.
The alert shows a price that differs at checkout.	The monitored page value may be promotional, region-specific, or otherwise different from the final checkout amount.	Treat Urlwatch as a page-change monitor and verify price, shipping, tax, eligibility, and availability with the retailer.

8. Reliability, performance, and cost

Urlwatch is a recurring fetch-and-compare workflow, so reliability depends on a working scheduler, retained state, reachable pages, stable selectors, and a configured reporter. A missed or failed scheduled run can delay detection. Browser-based navigate jobs can address JavaScript-rendered content, but they add browser setup and execution requirements compared with a regular URL fetch.

Each scheduled run makes another request to the page. The documented guidance recommends no more frequently than every 30 minutes. Consider the retailer’s terms and request load when choosing an interval. Urlwatch’s official documentation does not provide a price-monitoring performance guarantee or a cost estimate; the needed machine and hosting are outside the documented workflow.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request captures a page as PNG, JPEG, WebP, or PDF. It can accept cookie banners and remove more than 60 known consent platforms, newsletter popups, and chat widgets before capture. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. AI agents can use its MCP server tools to take screenshots, get page information, and capture PDFs. Its free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

This does not replace Urlwatch’s price-change comparison and alert workflow. It is useful when you need a clean visual capture of the current page or want an agent to inspect it. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Frequently asked questions

Will Urlwatch tell me immediately when a price changes?

No. It detects the change on a run, so the schedule determines how long it may take to notice.

Can I monitor more than one product?

Yes. Add a separate job for each product page in the job list, using a suitable selector and name for each.

Does a detected change mean the checkout price changed?

No. Urlwatch reports changed page output. Confirm the current price and purchase conditions with the retailer.

The monitored response may differ from what you see in a browser. The research-backed Urlwatch setup described here does not establish a retailer-specific authentication or location configuration; check the current documentation and validate the result you actually receive.