Noise-Filtered Website Change Monitor
Pricing
from $2.00 / 1,000 page checks
Noise-Filtered Website Change Monitor
Monitor public webpages for text changes. Use CSS selectors, ignore regex, normalized text and thresholds with persistent baselines and structured diffs for automated workflows.
Pricing
from $2.00 / 1,000 page checks
Rating
0.0
(0)
Developer
Fumiya Hanzawa
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
a day ago
Last modified
Categories
Share
Monitor public webpages for text changes while filtering common page noise. Select content with CSS selectors, ignore dynamic text with regex, persist baselines across runs, and receive structured diffs.
Features
- Stateful monitoring with a reusable stateKey and persistent baselines.
- CSS selectors for selected page sections.
- Text normalization removes scripts, styles and common page noise.
- Ignore regex patterns suppress timestamps or other dynamic text.
- A change threshold filters small edits; differences accumulate against the last accepted baseline.
- Structured Dataset output for automation, with statuses, ratios, timestamps and bounded diffs.
This Actor compares text. It does not determine business importance. It uses HTTP fetches without browser rendering, so JavaScript-only pages may not be suitable.
Input
{"targets": [{"url": "https://example.com", "selector": "body"}],"stateKey": "my-monitor","ignorePatterns": [],"minChangeRatio": 0.01}
Targets accept only url and optional selector. Unknown fields are rejected. Maximum 20 targets, 10 regex patterns of 200 characters each, and stateKey of 1–40 letters, digits or hyphens. An unmatched selector or empty extraction produces an error and preserves the previous baseline.
Output
One Dataset row per checked page: first_seen, unchanged, changed, or error. Successful rows
include url, selector, checkedAt, changed, changeRatio and summary. Changed rows have diffPreview
(up to 4,000 characters). Errors expose only exception classes, not third-party response bodies.
Check OUTPUT.errors even when the Run succeeds. OUTPUT also reports checked, changed, skipped,
duplicateTargetsSkipped, chargedCounts and stopReason. CHARGE_RECEIPTS records each billed count.
The first run establishes a baseline. Checks below the threshold preserve that baseline, allowing small changes to accumulate. Duplicate URL/selector targets in one run are processed once.
Pricing and spending limits
- page-check: $0.002 per successful page check, including baselines and unchanged pages.
- apify-actor-start: $0.00005 per started GB, minimum one event. This Actor uses 256–512 MB, normally one start event per run.
- Failed fetches/normalization are not charged as successful checks; the start event still applies.
- No automatic Dataset-item charge and no separate platform-usage surcharge in the offered PPE price.
Set maximum charge per run in Console or maxTotalChargeUsd via API. Allow at least $0.00205 for one start plus one check. A saved successful result is charged afterward. Processing stops when the event budget cannot cover another check. Your own storage/export costs remain subject to your Apify plan.
Limits: 2 MB uncompressed responses, 100,000 normalized characters, 35-second fetch deadline, 5 redirects and bounded regex time. Storage/billing failures fail the Run. Storage, charging and baseline writes are not atomic. The same cloud Run refuses replay after reboot/resurrection; a new Run is a new billable check. Do not delete PROCESSING_STARTED and restart old Runs. Exactly-once delivery across separate Runs is not promised.
Scheduling
Simultaneous Runs with the same stateKey in one account are not supported. Serialize calls and await completion. Space schedules beyond the configured timeout. Use different stateKeys for independent monitors. There is no distributed lock: overlapping Runs can overwrite newer baselines, repeat change signals and bill checks in each Run.
Data retention and deletion
Normalized page-body snapshots are saved in the named key-value store meaningful-change-<stateKey>.
This stable prefix preserves existing monitors. Each URL/selector/ignorePatterns combination gets
one key with its most recent accepted baseline. Removing a target does not delete stored data.
Full original HTML is not archived. No page content is sent to an LLM.
Dataset rows retain URLs, timestamps, comparison results and diff previews. Default key-value stores hold input, summary, charge receipts and the replay marker. Named snapshots remain until you delete them. Unnamed run storages follow your Apify plan's retention settings; naming them can preserve them indefinitely. You manage retention; review named stores at least every 30 days or automate deletion in your workflow. No automatic snapshot-expiry job resets your baselines unexpectedly.
Deletion procedure:
- Stop the monitor's schedules/integrations and wait for active Runs to finish.
- Console → Storage → Key-value stores: verify
meaningful-change-<stateKey>, then Actions → Delete. This resets all of that monitor's baselines; its next Run starts fresh. - For each related Run, identify and delete its Dataset and default key-value store, including unnamed storages. Deleting the named snapshot store alone does not remove Dataset diffs.
- Remove unneeded Runs/logs, exported files and downstream copies separately. Do not restart old Runs after deleting their replay marker. Never delete another monitor's resources.
For automation use authenticated DELETE /v2/key-value-stores/{storeId}, /v2/datasets/{datasetId}
and /v2/actor-runs/{runId} for verified IDs. Protect storage access using Restricted settings.
Actor visibility and storage visibility differ. Do not share tokens or storage links unintentionally.
Apify retention and deletion
Allowed targets and responsibility
Public HTTP/HTTPS pages only. No login, CAPTCHA or access-control bypass. Do not submit URLs or pages containing personal information, credentials or confidential information. Internal/non-public IPs, credential URLs and nonstandard ports are blocked. DNS is checked at connection time, connections are pinned to verified public IPs, and redirects are checked again.
You must confirm target terms, robots policies, rights and rate limits before submitting URLs. Public availability is not permission to scrape. The Actor does not automatically determine or enforce all robots.txt/site terms. The operator does not manually approve every customer URL; normal operation is unattended within these technical controls. New Actor publication and serious security or rights exceptions require human review.
Local development
Python 3.12 / Apify SDK 4.0.2, entrypoint python -m src. Use apify run or the prepared Windows
wrapper ../apify.ps1 run --input-file input.example.json.