Changes happen.
Choose what matters.
The optional AI relevance filter checks whether an already-detected change matters to you. Your normal rules still run first, and every captured change stays in history under your plan’s retention limits.
Start with a saved change
- Create your monitor normally. Choose public text or a new-item rule.
- Open monitor details and expand Only alert me about….
- Describe a specific change that matters, such as “Changes to cancellation fees or the refund window; ignore wording updates.”
- Choose a retained change, confirm the separate OpenAI consent and select Test on this change. The test starts immediately from the web app.
- Review the decision alongside the capture. On Pro or Business, select Apply these criteria to future matching changes and save.
A test never sends a notification, changes a prior decision or enables automatic filtering. Repeating a completed test with the same criteria and change reuses its result. Choose different criteria to compare another interpretation; completed new evaluations use the same allowance. A short cooldown and spending limits bound retries.
A literal “senior engineer” rule will reject “Staff developer” before AI gets a turn. For semantic job alerts, use a broad new-item rule, then describe the role in your relevance criteria. AI setup creates ordinary rules; AI summaries explain changes. Neither automatically enables this filter.
Three decisions. A visible fallback.
- Relevant: at least one captured change supports your criteria. Normal delivery is allowed.
- Not relevant: all evaluated items have complete supported evidence and are judged unrelated. Change alerts are filtered across email, webhook, Slack and Teams.
- Uncertain: evidence is ambiguous or a needed qualification is missing. Normal alerts continue.
- Filter not applied: the service is unavailable, the allowance is used, consent changed, evidence is unsupported or incomplete, or the request failed. Normal alerts continue with a visible explanation.
Every destination shares one saved automatic decision. Delivery retries cannot charge again or change it. Allowing an alert does not confirm delivery: schedules, enabled destinations, quiet hours, quotas and provider retries still apply.
If the site shows Observation mode, evaluations are recorded but normal alerts continue, including changes judged Not relevant. Existing observation decisions are never retroactively filtered.
Health, recovery, test notifications, invitations, no-change notices and weekly reports bypass relevance filtering. A matching capture still resets a no-change timer, even if its change alert is filtered. No change alerts →
The captured evidence sets the boundary
The first release supports public webpage text and new-item changes from webpage listings, RSS and Atom. Text evaluations use the full selected before-and-after captures within the input budget. Listing evaluations use captured titles, dates and snippets with a separate decision for every item.
Linked articles and job descriptions are not fetched. A title cannot prove that an unmentioned qualification is absent. A batch with an uncertain item allows the alert; a Relevant item also allows it. Suppression requires every qualifying item to be evaluated as Not relevant.
Inputs are limited to 24 KB including criteria and JSON, and at most 12 listing items. Truncated batches, fields that reach known capture limits, missing snapshots, and recognized credential, URL or instruction-like text cause normal delivery without a model request. These checks are conservative and cannot identify every sensitive value or malicious instruction.
Authenticated captures are excluded even if you later disconnect the site session. PDFs, sitemap-only entries, visual changes, direct price/stock rules and All conditions events remain outside this release. Mixed events containing unsupported rules also keep normal alerts. Select a focused text region when a whole-page capture is too large.
Structured output, exact evidence quotes and application checks limit what the model can do. They cannot prove that its interpretation is correct or eliminate prompt injection. Review test results and retained changes, especially for time-sensitive or consequential workflows.
A separate relevance allowance
- Free and Starter: 5 manual tests per workspace, shared across these plans for the lifetime of the workspace. Automatic filtering requires Pro or Business.
- Pro: 250 completed evaluations per UTC calendar month.
- Business: 1,000 completed evaluations per UTC calendar month, pooled across the workspace.
One completed test or automatic event evaluation uses one credit, including a valid Uncertain decision. An entire supported listing batch uses one credit. Provider/system failures, unsupported evidence and cached reuse do not use a customer credit. Failed provider attempts still count against service spending caps.
Automatic evaluations and tests share this allowance; AI summaries and AI setup have separate allowances. In-flight requests reserve capacity. Monthly credits reset at 00:00 UTC on the first day; the Free/Starter trial does not reset. Deleting monitors or changing plans does not renew a trial. At any limit, monitoring and normal alerts continue. View workspace usage →
Separate consent, shared visibility
With explicit consent, PageFluxer sends your criteria and supported captured text to OpenAI. Screenshots, cookies, raw HTML, target selectors and account identifiers are not input fields. Do not use confidential content or put credentials in your criteria.
Workspace members with monitor access can configure and test this setting, subject to current membership and plan access. They can see its criteria, saved decisions and retained captures. Settings changes are recorded in the workspace audit without copying the criteria.
Edits apply to future matching changes. Turning the filter off or changing criteria releases pending automatic alerts normally and prevents a late answer from suppressing them. A request already sent to OpenAI cannot be recalled. Completed decisions and already prepared messages remain fixed; previously filtered alerts are not resent.
Criteria versions, bounded explanations, supporting quotes and model/policy versions are stored with the source event and count towards history storage. One manual-test result per event is kept; a later test with new criteria replaces it. Event deletion removes these records. Monthly usage counters remain for up to 13 calendar months, daily attempt counters for 35 days, and the trial count for the life of the workspace. Provider retention and backups have separate policies. Privacy details →
Review and export every retained change
Change details show the automatic decision and why the filter did or did not apply. The report view includes filtered changes by default and can show only filtered alerts, uncertain decisions or fallbacks. CSV adds relevance status, verdict, explanation, delivery permission, observation mode and criteria version. Weekly reports include filtered changes and do not make new AI requests.
The public API and MCP change resources expose additive relevance metadata. A webhook that is sent includes it under change.relevance. A filtered change creates no ordinary webhook; retrieve it from history or the API. Consent and settings are managed in the web app in this release. The extension and ordinary monitor creation work as before.
Use the delivery history to verify provider acceptance. “Rule matched,” “relevance allows delivery” and “provider accepted” describe different stages. Reports and exports → · Notification delivery →