Automate Website Change Monitoring with n8n and Slack

Checking a page for changes by hand does not scale. Someone has to remember to open the tab, compare it against what they remember from last week, and flag anything unusual. Most of the time nothing changed, so the habit fades, and the one time something does change, nobody notices until a customer or a colleague brings it up.

This is a solved problem if you let a workflow do the watching instead. The Snapshot Site n8n node makes it straightforward to wire up a scheduled watcher that captures a page, compares it to a stored baseline, and posts to Slack only when the difference actually matters.

The Workflow: Website Change Watcher → Slack

This is one of the workflows in the public Snapshot Site n8n gallery, and it is a good template for understanding how the pieces fit together.

• A schedule trigger kicks things off. Hourly for something volatile like a pricing page, daily for something that changes rarely, like a terms-of-service page.
• A Snapshot Site node captures the current state of the target URL. This is a fresh, live screenshot taken at trigger time, not a cached copy.
• A compare node diffs the new capture against the stored baseline. You give it a "before" (the last known-good screenshot) and an "after" (the capture that was just taken), along with a comparison threshold. A lower threshold means the comparison is more sensitive to small differences; a common starting point is 0.1.
• The node returns a diff image and a mismatchPercentage. That number is what the rest of the workflow reasons about.
• An IF node checks the mismatch percentage against your threshold. Below it, the workflow simply stops — nothing worth reporting happened.
• Above it, a Slack node fires. The message includes the mismatch percentage and the diff image, so whoever sees it can tell at a glance what changed and how much.

Nothing in this chain needs a human to babysit it. The workflow runs on its own schedule, and it only speaks up when there is something worth speaking up about.

Why This Beats Manually Checking Pages

Manual checks fail quietly. They depend on someone remembering, someone having time, and someone actually noticing a subtle change rather than skimming past it. A scheduled comparison does not forget, does not get bored, and does not skim. It applies the same threshold every single time, so what counts as "a real change" is consistent regardless of who is on shift that week.

It also catches changes at the moment they happen instead of whenever someone next thinks to look. For anything time-sensitive — a competitor adjusting pricing, a partner site going down, a legal page getting edited without sign-off — the gap between "it changed" and "someone knows it changed" is the whole point.

Why Slack, Not Email

Email is where alerts go to be ignored. It gets buried under everything else in an inbox, it does not lend itself to a quick glance, and it is easy to file away as "read later," which usually means never.

Slack fits the way ops and marketing teams already work:

• It is visible in the moment. A message in a shared channel gets seen by whoever is online, not just whoever happens to check a particular inbox.
• The diff image renders inline. Anyone in the channel can look at the highlighted differences directly, without downloading an attachment or opening a separate tool.
• It is easy to react to as a group. Someone can thread a reply, tag the person who owns the page, or confirm the change was expected — all in the same place the alert landed.

Posting into a shared channel also turns a single alert into a shared source of truth. Everyone sees the same evidence at the same time, instead of one person's inbox being the only record that anything happened.

Real Use Cases for This Workflow

• Watching a competitor's pricing page. Get notified the moment pricing, plans, or terms shift, instead of finding out secondhand.
• Watching your own marketing or legal pages. Catch unauthorized edits to a pricing page, a terms page, or a landing page before they sit live for days.
• Watching a partner's page for outages or redesigns. If a partner site goes down or gets restructured without notice, you find out from your own monitoring rather than a support ticket.

Keep the Baseline Fresh

One thing worth planning for up front: the stored baseline needs to be updated periodically, not just set once and forgotten. Pages change for perfectly normal reasons — a blog roll updates, a banner rotates, a date stamp ticks over — and if the baseline never moves, the workflow ends up alerting on routine content updates instead of the changes you actually care about.

The fix is simple: build in a step (manual or scheduled) that replaces the stored baseline with the current capture once you have confirmed a change is expected. That keeps the comparison meaningful over time, instead of degrading into noise that gets muted a week in.

Once it is wired up, this workflow turns "did anything change on that page" from a question someone has to remember to ask into something that answers itself. Snapshot Site provides the capture and comparison engine behind it, ready to drop into an n8n workflow like this one.