How to Monitor a Competitor's Website for Changes

Most competitive intelligence starts as a bookmark folder someone opens every so often: the competitor's homepage, their pricing page, maybe their changelog if they have one. It works until the team gets busy, the folder goes stale, and a competitor ships a new integration, repositions their homepage headline, or quietly raises a price, and nobody on your team notices for weeks.

A single price watch catches one signal on one page. To actually monitor a competitor's website, you need eyes on every page that tells you something: the homepage for messaging shifts, the pricing page for plan and price changes, and the changelog or blog for new features and launches. Rendex Watch does this with one watch per page, all under the same key and credit pool, each one rendering in real Chrome on a schedule and alerting you the moment something moves.

One page misses the story

A competitor's pricing page tells you when a number changes. It tells you nothing about a repositioned headline on the homepage, a new "Enterprise" tier mentioned only in a blog post, or a changelog entry announcing the exact feature your roadmap has been planning for next quarter. Each page type carries a different signal, and a single watch only ever tells you about the one page it points at.

The fix isn't a smarter single watch, it's more watches pointed at the pages that actually matter: the homepage for positioning, the pricing page for plans, and the changelog or blog index for launches. All three run independently, on their own schedule, and roll up under the same account, so watching a competitor's whole site is a handful of API calls, not a monitoring project.

Create a watch for each page

Every watch is one call to POST /v1/watches (or createWatch in the JS/TS SDK). The only required field is url; a sensible check interval and diffMode: "both"(visual and text diffing together) are the defaults, so watching three pages on a competitor's site is three calls with different URLs and intervals:

watch-competitor-site.ts

import { Rendex } from "@copperline/rendex"

const rendex = new Rendex("rdx_YOUR_KEY") // https://rendex.dev/login

const pages = [
  { url: "https://northwindcloud.com", name: "Homepage", intervalMinutes: 360 },
  { url: "https://northwindcloud.com/pricing", name: "Pricing", intervalMinutes: 180 },
  { url: "https://northwindcloud.com/changelog", name: "Changelog", intervalMinutes: 60 },
]

for (const page of pages) {
  const watch = await rendex.createWatch({
    ...page,
    notifyEmail: "you@youraccount.com",
    webhookUrl: "https://your.app/hooks/rendex", // Starter+
  })
  console.log(`Watching ${watch.name}: ${watch.id}`)
}

The changelog watch checks every hour because launches are the highest-value signal and the cheapest to catch early; the homepage checks every six hours because messaging changes less often. Each interval is only a floor your plan enforces, not a fixed schedule you have to match everywhere, so scope the frequency to how much a page actually moves. Before committing to a schedule, run the same config through POST /v1/watches/test (or try it directly with the free website watch preview tool) to confirm the page is reachable and see what a check would capture, no watch created and no credit spent on a bad config.

Scope a watch to a specific section with renderParams.selector when the rest of a page is noisy. A homepage watch pointed at the hero and nav ("header, .hero") catches a headline or CTA change without tripping on a rotating testimonial carousel further down the page. Leave selector unset and Watch diffs the whole page, which is usually right for a changelog or blog index where the entire feed is the point.

How many pages of one site you can watch

Two limits apply, and they answer different questions. The first is your plan's total watch count: Free carries 1 watch, Starter 10, Pro 50, Enterprise 1,000 (counts are total, active plus paused). The second is a per-host cap that exists independent of plan: at most 10 active watches may point at the same host at once. That cap is generous enough to cover a homepage, pricing page, changelog, docs index, and a handful of product pages on one competitor without coming close to the limit, and it applies on every plan, Free included.

Check interval floors scale by plan and set how fast the fastest watch on that host can run: Free checks once a day, Starter as often as hourly, Pro as often as every 30 minutes, and Enterprise as often as every 5 minutes. A Starter plan watching three pages on one competitor, for example, could run the changelog hourly and the homepage every six hours, all within the same per-host cap and the same 10-watch plan total. See the Watch API reference for the current numbers before you plan a larger rollout.

What an alert looks like

Each watch runs independently, so a change on the changelog alerts you without waiting on the pricing or homepage checks. Every alert (email, or a signed webhook on Starter+) carries the before and after state and, on Pro and Enterprise, a one-sentence AI summary of what moved:

Rendex Watch dashboard with three watches on one competitor host: homepage and pricing unchanged, changelog flagged changed 2 hours ago — Three watches on one host, each checking a different page on its own schedule

The webhook payload for a single change carries the full before, after, and diff-overlay URLs plus a structured text diff, the same shape whichever page fired it, covered in detail (including the raw JSON) in the competitor price monitoring walkthrough. Routing three watches into one handler is a matter of branching on the payload's watchId or url to know which page fired.

Production considerations for a multi-page watch

Name every watch. The optional name field is what shows up in alerts and in listWatches results, and with several watches on one host it is the difference between an alert you can triage in seconds and one you have to look up.
Suppress known noise per page. renderParams.ignoreText strips volatile substrings (a timestamp, a visitor counter) before the text diff runs, and suppressWhilePresentholds off alerting while a string like "Loading…" is still on the page. A changelog feed and a pricing card usually need different ignore lists.
A scope change re-baselines. Editing a watch's url, selector, or output format clears its stored baseline, since the next capture is a different shape than the last one. Expect one "first look" run after any such edit before diffing resumes.
Alerts are plan-gated, watches aren't. notifyEmail works on every plan and defaults to your account email if unset; webhookUrl delivery requires Starter or above. The watches themselves, and the per-host cap, apply the same way regardless of plan.
Cost stays predictable.Each scheduled check draws one credit from your normal Rendex credit pool, whichever page it is, and a failed check is refunded automatically. Three watches on different schedules don't need separate billing to track, just more credits in the same pool.

For the full feature rundown, including how the visual and text diff engines work together, see the Rendex Watch launch post, and for a side-by-side look at Watch against dedicated monitoring tools, the website monitoring tools comparison covers where a purpose-built monitor still wins, and the Visualping alternative post digs into that specific comparison for developers.

Get started

Watching a competitor's whole site, not just one page, is the subject of the website monitoring use case, which covers the same setup in more depth alongside other targets worth watching (your own site, a partner's status page, a vendor's docs). If you already use Rendex for screenshots, PDFs, or extraction, Watch needs no new account or key, it draws from the same rdx_ key and credit pool.

Start at rendex.dev/login. The free tier includes one watch on a daily check alongside 100 render calls a month, no credit card required, enough to point at a competitor's pricing page and see the alert before you scale up to a full multi-page watch.