Docs

What you picked gets a green frame, with a “🎯 Picked place” tag above it and an × mark that drops it. Those two are all that sits on the frame (anything more would cover the very thing you are looking at). Pick two or more places to take out and each tag gains a ① ② number, with the same number on the row below.

• To go further in, click that element directly. There is no button for it.
• To widen outwards, press “↔ Widen the area” in the panel. Clicking cannot take you back to a parent.
• If you widened too far, “↩ Undo one step” next to it returns you to the previous selection.
• To start over, press “Remove the place being picked”. Only the current one goes. To clear everything, use “Remove every place”.
• For parts you do not want to hear about, such as adverts or timestamps, switch the row at the top of the panel to “Places to remove” first, then pick them.
• To combine two or more separate areas into one monitor, use “＋ Add a place” at the bottom of the panel.
• If a list is split across pages, “Pager” in the same row lets you point at the pagination link.

The frame colours mean different things. Tell them apart by the name above the frame.

• 🎯 Picked place (green) — what you have selected
• 🚫 Place to take out (red) — changes here are ignored
• 📦 Added place (purple) — a second or later selection
• Pager (orange) — the link used for pagination

If a tag with a count, such as ⚠ 3 matches, appears, other elements share the same shape. Saving it as is means that a mere change in page structure sends it looking somewhere else. Trying “Widen the area” to take in the surroundings often settles it.

“Remove every place” at the bottom of the panel clears the selections, the exclusions and the pagination link together. To remove only the current one, use “Remove the place being picked” next to it.

When there are too many, work down this list.

1. Put advert slots, and places like “3 minutes ago”, into “Places to remove”. Relative timestamps are ignored automatically by default.
2. Change the mode to “Text changes”.
3. Under “❸ Fine-tune” → “What is compared”, use “Changes to ignore” to set how many characters must change before you hear about it.
4. Under “❹ Set up notifications”, use “When not to notify” to stay quiet when certain words appear.

When too few arrive, or none, look at the state on the card first. If it says “No change”, nothing really changed. Anything else, read the entries below.

A page that requires signing in cannot be fetched by an ordinary patrol. The session you have in the browser is not carried into the background fetch that a patrol uses.

Turn on “Wait for the page to load further” under that monitor's “❸ Fine-tune” → “How it is fetched”, and the page is opened with the same session as your normal browser. If you are signed in to that site, it is fetched in that state.

Sites that answer with a bot check or a verification screen (“are you a robot” and the like) are declined at the point you try to add them. Picking a different area will not fix that.

If you are unsure, leave it on “Content changes (images and link targets included)”. Start there, and change it once the notifications feel like too many.

• Tell me when the content changes — text, and also images and link targets (the default).
• Tell me when the text changes — text only. Least likely to trip over a rotating advert, so the fewest false alarms.
• Follow a price or stock number — lets you set a condition such as “when it drops below 1,000”. When you press “Check the content”, the decimal point is set from how the page writes numbers (such as 1.299,99 €), and “How to read the number” shows the value it read. You can pick again if it is wrong.
• Tell me when the count goes up or down — stays quiet if the contents changed but the count did not.
• Tell me when links appear or disappear — stays quiet if only the link text changed.
• Read the page's underlying data — resilient to class names changing, but you must say which part of the data to read.

A list item does not have to be a table. Table rows, bullet lists, separated boxes — if one row is one item, you select it the same way.

What does not work is a table where one row is not one item. A weekly forecast, for instance, puts the days across the columns, so one day's content is split down several rows. With that shape, whatever you pick yields only one kind of value.

You are told at the moment you pick. If you click two “list items” on the page and the arrangement does not look like one row per item, a yellow frame says so. It does not stop you — sometimes that is exactly what you want.

Put the “next” link into “Where the pager is” under “❸ Fine-tune” → “How it is fetched”, and the pages are joined and treated as one monitor. The surest way is the “Pager” tab on the picking screen.

It joins 3 pages by default, up to 5 pages. The more pages, the longer each fetch takes.

A “show more” button that has to be pressed works too. In that case the button is pressed on every fetch. Buttons inside a form cannot be chosen, because that risks submitting or purchasing over and over.

⚠️ If one of the pages could not be fetched, the whole monitor is treated as failed. Comparing against a list that came back short would report “fewer items” when nothing had actually gone.

Browsers stop drawing pages that are not on screen. So an ordinary patrol may find that scrolling does not pull in anything new.

When a card says “It may not have been read in full”, turn on “Wait for the page to load further” under that monitor's “❸ Fine-tune” → “How it is fetched”. A small window flashes open on each fetch; it opens behind your other windows and closes on its own.

Comparing two fetches that were both cut short would report “changed” forever while nothing happened. To avoid that, only the range that is certainly present in both fetches is compared, and if that part matches you see “No change in what we could read”.

The overall default is set in Settings. The shortest is 1 minute. A per-page interval is changed in the header of that monitor's own screen.

Shorter means hearing sooner, but it also loads the site more, and your browser more. There is no point checking a page that changes monthly every five minutes. Shortening only the fast-moving pages wastes the least.

On automatic patrols the fetch time is shifted by a few seconds each time, so each interval varies slightly (→ The rules we follow towards the sites).

Why it cannot go below 1 minute. Three reasons.

1. The browser will not wake us any more finely than that. The mechanism an extension uses to run at a fixed interval has a floor set by the browser. Even if a shorter value could be chosen, it would be thinned out to that floor in practice.
2. It cannot be shorter than one full round. How many seconds it takes to visit every monitor you have added is estimated, and intervals below that are not offered. If they were, the next due time would arrive before the previous round finished, and it would simply be skipped in silence. The estimate is in seconds and the interval is in minutes, so it rounds up (40 seconds means a floor of one minute).
3. Out of consideration for the sites. Even once a minute is 1,440 visits a day. Shortening only the fast-moving pages wastes the least.

The floor rises on its own with the number and kind of monitors you have added. The Settings screen shows what the current floor is and what that number is based on.

⚠️ Patrols stop while the machine sleeps. To keep it running, turn off system sleep and let only the display switch off.

Above “Pages being monitored” there are tabs that filter by state (All / Unread / No change / Needs attention / Stopped, plus 🗑 Trash when there are deleted monitors), and at the right end three buttons: search, sort and select. Counts appear on the tabs, so you can see how many are failing without opening anything.

The search button opens a search box under the tabs; closing it clears the search. The sort button opens a menu: choose from “By date added”, “By last fetched”, “By patrol interval” and “By name”, and switch ↑↓ below them. When the order differs from the default (date added, descending), a dot appears on the button. Your choice is remembered for next time. Rows with the same value fall back to name order.

To act on several at once, press “Select”. Rows become checkable, and you can mark as read, pause, resume or delete in bulk. Press “Done” when you are finished. Monitors hidden by the search or a tab drop out of the selection, so bulk actions only touch what you can see.

⚠️ “Mark as read” asks first. Being read is not itself irreversible, but which ones had updates can no longer be told apart afterwards.

When you delete a monitor, a “🗑 Trash” tab appears at the end of the tabs on “Pages being monitored”. Press “Restore” to bring it back with its settings and update history.

Choose how long to keep them under “Days to keep in the Trash” in “Settings” (30 days by default). After that, they are deleted permanently. To delete them sooner, press “Delete permanently” or “Empty Trash”.

The picker (“👀 Pick it on the page”) means you never have to write one, but sometimes typing is faster, or you want to be more precise.

Almost any CSS selector your browser understands can be written as is. An id such as #news-list, a class such as .item-card .price, an attribute such as li[data-kind="item"], and also :has() and :not() — enough to say “only rows that contain a product link”.

Some forms do not work. Anything that depends on mouse state, such as :hover, and text added through ::before, cannot be read. What is being looked at is the page as it loaded.

Pointing at the wrong thing never comes back as “No change”. When nothing at all is found, the card says “Needs attention”.

Avoid class names you cannot read meaning into. Classes with random characters in them, such as .css-7f3a1b or .Row-sc-8kf2d1, change the moment the site is redeployed. An id, or an attribute starting with data-, lasts far longer.

One more thing: what reads the page differs with how it was fetched. When we wait for the page to load, we see what the browser itself built; otherwise we re-read the fetched HTML ourselves. On intricate selectors the count the picker showed and the count during a patrol can occasionally disagree. Use “Check the content” to confirm it reads before you register.

Put a word such as Loading into “Text that postpones comparing” under “❸ Fine-tune” → “What is compared”, and when a fetch catches the page before it has produced its real content, the comparison is skipped entirely.

⚠️ If you name a string that is always on the page, the monitor stays paused. While it is held, the card says so, and if it continues you are notified.

When you monitor a list, what is on the page is narrowed in three steps: read → record → show. Anything dropped at one step does not reach the next. The first two are set under “🗂 What a monitor reads and records” in Settings.

• ① Rows read from one page — how many rows are read per fetch. If the page lists 500 and this is 300, only 300 are looked at.
• ② Items recorded per update — of those read, how many of the added or changed ones are kept in the record.

While ① is being hit, “gone” is not reported. There is no way to tell whether an item really left the page or was merely pushed past the limit. For a list where you want to follow removals, set ① higher than the real count.

While ① is reached, what we report as new can also contain repeats. An item that slides inside the limit as the order shifts looks newly arrived even when nothing about it changed.

Choose it under “🎨 Appearance” → “Display language” in Settings. There are ten options: follow the browser, or one of the nine languages. Choosing one reloads the screen.

It has nothing to do with the language of the pages you monitor. You can monitor an English page from a Japanese interface, and the other way round.

Webhook messages are also built in whatever the display language was at the time. Changing the language later does not rewrite messages already sent, or past records. They stay in the words they were recorded in.

Register a webhook URL in “Notifications”. Five services are supported.

• Discord — Open the settings of the channel you want alerts in → “Integrations” → “Create Webhook” → “Copy Webhook URL”. Official help (Discord)
• Slack — Add the “Incoming Webhooks” app to your workspace → choose the channel to post in → copy the webhook URL it gives you. Official help (Slack)
• Microsoft Teams — On the channel you want alerts in, “…” → “Workflows” → choose “Send webhook alerts to a channel”, pick the team and channel, and save → copy the webhook URL it shows. You can create it in a channel of Teams for work (such as Microsoft 365). The free version of Teams may not have this option. Official documentation (Microsoft Teams)
• Google Chat — Click the name of the space → “Apps & integrations” → “Add webhooks” → name it and save → “More” → “Copy link”. This needs a Google Workspace account (Business or Enterprise); personal Gmail accounts can’t create one. Your organization’s admin must also allow webhooks. Official documentation (Google Chat)
• ntfy — Register a topic name of your choosing in the ntfy app on your phone (iOS / Android), then enter https://ntfy.sh/your-topic. Handy for reaching a phone. Official site (ntfy.sh)

You can register several destinations and name them. Keeping Work and Shopping apart means each monitor can choose where it goes.

The choice lives under that monitor's “❹ Set up notifications” → “Destination”. Leave it unset and it goes to the first destination in the list.

Three choices under “❹ Set up notifications” → “How notifications are split”.

• One alert with everything (default) — updates arrive together. On webhooks, changed items are sent 10 per message, and every item arrives.
• One alert per list item — browser notifications tell you about each list item separately (depending on your OS and browser settings, they may be grouped once there are many). ntfy also gets one message per item, but they may be combined once there are many. Other webhooks get every item, 10 per message.
• Only that there was an update — it says an update happened, without saying which item (the update history still records it).

“One alert per list item” suits you if you want to judge from the notification alone.

⚠️ Webhooks get changed items 10 per message, and every item arrives. To avoid a flood of messages at once, adjust the place to monitor or the rows read from one page.

⚠️ The free ntfy.sh allows 250 messages a day. Anything beyond that waits until the limit resets.

In “Notifications”, choose the days and times under “🌙 Quiet hours”. If the end time is earlier than the start time, quiet hours run until the next morning (for example 23:00–07:00).

• Patrols keep running. Updates still show in “Pages being monitored” as usual.
• Alerts such as “Could not fetch” are held too. They are included in the summary with ⚠️.
• The summary lists up to 20 entries and gives only the count of the rest. You can read the details in each monitor’s update history.
• Per-monitor mentions and opening messages are not added to the summary.
• If quiet hours ended while the browser was closed, the summary arrives the next time you open it.

When sending to a webhook fails, these panels appear at the top of “Pages being monitored”.

• ⚠️ Notifications won’t arrive until these destinations are fixed — the URL was deleted (HTTP 404), it isn’t a supported destination’s URL, access hasn’t been allowed, the chosen destination no longer exists, and so on. Each destination shows the reason and a “Fix the destination”, “Allow” or “Choose a destination again” button. After you fix it, it disappears the next time a message goes through.
• ⏳ “… items haven’t been sent yet” — when the destination didn’t process a message properly, or ntfy’s daily sending limit was reached. Sending is retried at intervals and continues once it goes through. “Delete what’s waiting” removes what is waiting.
• ⚠️ Some notifications couldn’t be sent — for instance when nothing went through within 24 hours of finding the update. Each destination shows the count and when the updates were. “Clear” closes it.

The update itself is not lost. What was detected is in the history, so you can open that monitor and see it.

1. Fetch the page's HTML as it is (lightest, and the default)
2. Read the structured data the page carries internally (resilient to class names changing)
3. Only when neither works, actually render the page in a hidden tab

Which one to use is decided when you add the monitor, and is not re-decided on every patrol. The icon on the card tells you which is in use.

A page drawn by JavaScript is empty if you only take its HTML. So the page is opened for real in a hidden tab and closed as soon as it has drawn.

This does not clutter your browsing history. The history entry for a page opened by a patrol is removed when the tab closes.

It does, however, remove more than ours. The removal facility the browser provides deletes every visit to that page. There is no way to remove a single visit. So your own visits to that page go too. The more likely you are to visit a page yourself, the more likely this is to matter.

If that bothers you, turn off “Wait for the page to load further” under that monitor's “❸ Fine-tune” → “How it is fetched”. The page is then never opened for rendering, so the history is never touched.

If “Wait for the page to load further” is on for that monitor, what flashes open is a small window rather than a hidden tab. It opens behind your other windows, so it does not get in the way, but it does appear.

Nothing is done to the security settings of the sites you monitor. You can keep using them exactly as before.

• Requests to the same site are made one at a time, in order. It never hits a site all at once.
• When we visit the same site more than once in a row, we leave a little space between the visits. If the site declares a wait in its robots.txt, we follow that instead (up to 15 seconds).
• The shortest patrol interval is one minute, and it cannot go below that.
• robots.txt is read and declined places are not fetched. Only the monitors that truly need it can visit anyway, one by one (“Add a monitor” → “❸ Fine-tune” → “How it is fetched” → “Visit the page even if robots.txt declines”; for an existing monitor, start from “⋯” → “✏️ Settings and editing”). You write down a reason when you make the exception. Whether to visit it anyway is your judgement and your responsibility.
• After a failed fetch it waits longer before retrying. It does not keep hammering a page that keeps failing.
• On automatic patrols, the start of each visit to a site is shifted by a few seconds every time. Fetching at the same second every time looks mechanical. Because of this, each interval runs a little shorter or longer than the setting (on average it matches the setting). Nothing is shifted when you press “Patrol now”.

⚠️ These are courtesies towards the sites, not a guarantee that the access will not be judged mechanical. How it is judged and handled is up to each site.

⚠️ Checking the terms of the sites you monitor is your own responsibility.

There is no limit on the number, nor on how much is stored. The extension asks the browser for permission to lift the storage limit, so it is never stopped by capacity.

If anything, the thing to watch is speed. Each patrol starts by reading all of the monitor settings, and so does the list on screen. Each one is small, though: even several hundred monitors do not make either noticeably slower (we have checked this ourselves).

Fetched content and the history of updates are kept apart from the monitor settings, so however much they grow, the list and the patrols do not get heavier. They only take up space on the device; how much is in use right now is shown under “🗂 What a monitor reads and records” in “Settings”. How much history is kept is set by ① and ② on the same card and by “Updates kept in history” on each monitor.

Keeping the full text of every fetch would get heavy, so only the previous generation is kept for comparison. If the saving itself fails, the card says so.