FetchTheChange

Email notifications for webpage changes get buried. By the time someone opens their inbox, the competitor's price has already moved, the product has sold out again, or the status page has gone back to green. Slack puts the alert where the team is already working — in a channel, visible to everyone who needs to know, the moment the change happens.

Continue the read on the blog.

You check the same webpage every day. Maybe it's a product page where you're waiting for a price drop. Maybe it's a competitor's site where you want to know the moment they change their pricing or launch a new feature. Maybe it's a government page that publishes updated deadlines, or a job board where your dream company occasionally posts new roles. You open the page, scan it, see nothing has changed, and close the tab. You've been doing this for weeks — maybe months — and you know there has to be a better way.

Continue this read over at my blog.

When people hear "website change monitoring," they immediately think of price tracking. And fair enough — watching for competitor price changes is the most obvious use case and the one most tools market around. We've covered price monitoring in depth separately, and it's a genuinely valuable application.

But website monitoring is a much broader tool than that. Any time information lives on a web page that matters to your work, and you need to know when it changes, you have a monitoring use case. The common thread isn't commerce — it's that someone somewhere updates a webpage, and you need to know about it without manually refreshing every day.

This article covers five use cases that have nothing to do with prices. For each one, we walk through a real scenario, explain what to monitor, what kind of CSS selector works best, and what a meaningful alert looks like. These are use cases drawn from actual monitoring patterns — not hypotheticals.

Continue the read on my blog.

You set up a website monitor. You pick the element you want to track, configure your CSS selector, and everything works perfectly. For days, maybe weeks, the monitor hums along — capturing changes, sending alerts, doing exactly what it should. Then one morning you check your dashboard and find nothing. No data. The selector stopped matching.

This is the single most common reason website change monitors stop working. Not bot blocking, not rate limiting, not CAPTCHAs — selector breakage. The element you were targeting still exists on the page, the value you care about is still there, but the path your selector used to reach it no longer works. The monitor sees an empty result and, depending on the tool, either alerts you to an error or — far worse — silently records nothing and moves on as if everything is fine.

It happens because modern websites are not static documents. The DOM is a moving target. Class names change between deployments, elements get restructured during feature work, and front-end frameworks generate unpredictable markup that shifts every time the development team pushes an update. The page looks the same to a human visitor, but the underlying structure your selector depends on has changed completely.

This article explains the five main reasons CSS selectors break on modern websites, how to write selectors that survive longer, and what to do when they inevitably fail.

Continue the read in my blog.

Monitoring competitor prices is a common practice in ecommerce, SaaS, and retail. Whether you're tracking a rival's product page or watching for price drops on a supplier's site, having accurate and timely data can directly impact your pricing decisions.

But most price monitoring setups fail — and not in the way you'd expect. The real problem isn't usually getting blocked outright. It's that your monitoring quietly stops working without any warning. Your tool keeps running, reporting no changes, while the actual price has shifted multiple times.

Continue reading in my blog.

There are dozens of website change monitoring tools available today. Each has its strengths and tradeoffs. This article provides a factual comparison to help you choose the right one for your use case.

TL;DR

• FetchTheChange — Best for value-level monitoring with explicit selector failure detection and recovery assistance

• Distill — Best for power users who need browser automation, macros, and recorded actions

• Visualping — Best for visual/screenshot-based monitoring with easy setup

• Hexowatch — Best for teams needing multiple watch types (visual, keyword, source, tech stack)

Continue this read in my latest blogpost.

Hey Indie Hackers!

Problem: Many website change monitors break silently when pages are JavaScript-heavy or when the DOM structure changes.

FetchTheChange is my attempt to fix that. It monitors any value on a page (not just prices) and—when a selector stops matching—helps you recover instead of failing silently.

Key features:

• Works on modern, JavaScript-heavy sites

• Monitors any value (prices, availability, metrics, text, status messages)

• Shows clear failure states (e.g. “selector missing” vs “blocked”)

• Includes a built-in “Fix Selector” helper that suggests working selectors

Here’s a screenshot of the selector-fixing flow:

Live demo:

https://ftc.bd73.com

I’d love honest feedback:

• Would you use this? For what use case?

• Is the “Fix Selector” flow clear enough for non-technical users?

• What would you need before paying for it?

Happy to answer any questions — thanks for taking a look!